Settlements Oracle FLEXCUBE Universal Banking Release 11.3.1.0

Settlements Oracle FLEXCUBE Universal Banking Release 11.3.1.0

Settlements

Oracle FLEXCUBE Universal Banking

Release 11.3.1.0.0EU

[April] [2012]

Oracle Part Number E51534-01

Settlements

Table of Contents

1.

ABOUT THIS MANUAL ................................................................................................................................ 1-1

1.1

I

NTRODUCTION

........................................................................................................................................... 1-1

1.2

A

UDIENCE

.................................................................................................................................................. 1-1

1.3

O

RGANIZATION

.......................................................................................................................................... 1-1

1.4

C

ONVENTIONS

U

SED IN THIS

M

ANUAL

....................................................................................................... 1-1

1.5

G

LOSSARY OF

I

CONS

.................................................................................................................................. 1-2

1.6

R

ELATED

D

OCUMENTS

............................................................................................................................... 1-3

2.

THE SETTLEMENTS SERVICE ................................................................................................................. 2-1

2.1

I

NTRODUCTION

........................................................................................................................................... 2-1

2.2

M

AINTAINING

BIC D

IRECTORY DETAILS

.................................................................................................... 2-1

2.2.1

Specifying BIC Code details .............................................................................................................. 2-2

2.2.2

Request for Transfer .......................................................................................................................... 2-5

2.2.3

Maintaining BIC directories .............................................................................................................. 2-5

2.2.4

BICPlusIBAN support ........................................................................................................................ 2-6

2.2.5

Uploading BIC files ......................................................................................................................... 2-10

2.2.6

Operations on a BIC record ............................................................................................................ 2-11

2.3

M

AINTAINING

U

LTIMATE

B

ENEFICIARY DETAILS

..................................................................................... 2-13

2.4

M

AINTAINING MULTI MODE SETTLEMENT DETAILS

.................................................................................. 2-14

2.5

C

APTURING

S

ETTLEMENT

P

REFERENCES FOR A

C

USTOMER

..................................................................... 2-17

2.5.2

Capturing Details of Parties Involved in Payments ......................................................................... 2-21

2.5.3

Capturing Details of Parties Involved in Receipts ........................................................................... 2-25

2.5.4

Capturing Cover details ................................................................................................................... 2-28

2.5.5

Maintaining Local Clearing Details and Cover Details for Customer Settlement Instructions ...... 2-28

2.5.6

Specifying the default MT 103 details .............................................................................................. 2-31

2.6

T

HE

S

EQUENCE IN WHICH

S

ETTLEMENT

I

NSTRUCTIONS ARE RESOLVED

................................................... 2-32

2.7

P

ROCESSING

S

ETTLEMENTS

...................................................................................................................... 2-33

2.7.1

Capturing Account Details .............................................................................................................. 2-35

2.7.2

Capturing Message Details for a contract ....................................................................................... 2-37

2.7.3

Capturing Party Details ................................................................................................................... 2-41

2.7.4

Default MT 103 details .................................................................................................................... 2-47

2.7.5

Amending Settlement Details ........................................................................................................... 2-49

2.8

SWIFT

MESSAGES HANDLED BY

O

RACLE

FLEXCUBE ........................................................................... 2-49

2.8.1

Payment Message - MT 100 (103) ................................................................................................... 2-49

2.8.2

MT 100 (Customer Transfer) ........................................................................................................... 2-52

2.8.3

MT 102 (Consolidated Customer Transfer with Cover) .................................................................. 2-54

2.8.4

MT 200 (Financial Institution Transfer for its Own Account) ......................................................... 2-57

2.8.5

MT 202 (General Financial Institution Transfer) ............................................................................ 2-58

2.8.6

MT 205 (Financial Institution Transfer Execution) ......................................................................... 2-59

2.8.7

MT 202COV / 205COV .................................................................................................................... 2-59

2.8.8

MT 210 (Notice to Receive) ............................................................................................................. 2-62

2.8.9

MT 320 (Fixed Deposit Confirmation) ............................................................................................ 2-63

2.8.10

MT 300 (Foreign Exchange Confirmation) ..................................................................................... 2-65

2.8.11

MT 400 (Advice of Payment) ........................................................................................................... 2-66

2.8.12

Payment Message Generation for MT300/320 ................................................................................ 2-67

2.8.13

MT 756 (Advice of Reimbursement or Payment) ............................................................................. 2-67

2.8.14

MT 012 (ACK Status Acknowledgement) ......................................................................................... 2-68

2.8.15

MT 019 (NAK Status Acknowledgement) ......................................................................................... 2-68

2.8.16

MT110 (Advise of Cheque) .............................................................................................................. 2-70

2.8.17

MT 362 (Interest Rate Reset/Advice of Payment) ............................................................................ 2-72

2.9

G

ENERATION OF

MT920 M

ESSAGES

........................................................................................................ 2-75

2.9.1

Generating MT920 Message ............................................................................................................ 2-75

2.9.2

Processing of Incoming 920............................................................................................................. 2-77

3.

NETTING PAYMENTS ACROSS MODULES ........................................................................................... 3-1

3.1

I

NTRODUCTION

........................................................................................................................................... 3-1

3.1.1

Maintenance required for Netting Payments in Oracle FLEXCUBE ................................................ 3-1

3.1.2

Capturing the Agreement related details ........................................................................................... 3-1

3.1.3

Maintaining netting related information at the contract level ........................................................... 3-4

3.1.4

Maintenance pertaining to the Route for settling payments .............................................................. 3-5

3.2

G

ENERATING THE NETTED

FT..................................................................................................................... 3-6

3.2.1

Viewing details of Netted Contracts .................................................................................................. 3-6

4.

ANNEXURE - A - FILE FORMATS ............................................................................................................. 4-1

4.1

I

NTRODUCTION

........................................................................................................................................... 4-1

4.2

BIC

RECORD UPLOAD

................................................................................................................................. 4-1

4.3

R

ECORD FILE FORMATS

.............................................................................................................................. 4-1

5.

SCREEN GLOSSARY .................................................................................................................................... 5-1

5.1

F

UNCTION

ID L

IST

...................................................................................................................................... 5-1

1. About this Manual

1.1

Introduction

This manual is designed to help you get acquainted with the manner in which contracts in a product are settled in Oracle FLEXCUBE.

It takes you through the various steps involved in processing a Settlement.

You can further obtain information specific to a particular field by placing the cursor on the relevant field and striking <F1> on the keyboard.

1.2

Audience

This manual is intended for the following User/User Roles:

Role Function

Back office clerk

Back office managers/officers

Input functions for contracts

Authorization functions

Product Managers

End of day operators

Product definition and authorization

Processing during end of day/ beginning of day

Financial Controller/Product Managers Generation of reports

1.3

Organization

This manual contains the following chapters:

Chapter 1

About this Manual gives information on the intended audience. It also lists the various chapters covered in this User Manual.

Chapter 2

The Settlements Service details the procedure to set up Settlement details and the processing of Settlements. It also lists the SWIFT messages handled by Oracle FLEXCUBE.

Chapter 3

Netting Payments Across Modules explains the process of netting transactions that have some common features

Chapter 4

Annexure A - File Formats lists out the upload file formats

1.4

Conventions Used in this Manual

Important information is preceded with the symbol.

1-1

1.5

Glossary of Icons

This User Manual may refer to all or some of the following icons.

Icons Function

New

Copy

Save

Delete

Unlock

Print

Close

Re-open

Reverse

Template

Roll-over

Hold

Authorize

Liquidate

Exit

Sign-off

Help

Add row

Delete row

Option

List

Confirm

1-2

Icons Function

Enter

Query

Execute

Query

Refer the Procedures User Manual for further details about the icons.

1.6

Related Documents

For further information on procedures discussed in the manual, refer to the Oracle FLEXCUBE manuals on:

Common Procedures

1-3

2. The Settlements Service

2.1

Introduction

The Settlements sub-system is part of the core of Oracle FLEXCUBE. This system is a central money settlement service that interfaces with the other modules of Oracle FLEXCUBE.

In Oracle FLEXCUBE, the Settlements and Messaging systems are closely associated. The

Settlements system provides for a common set up of money settlement accounts and routes. The

Messaging system, on the other hand, handles the generation of settlement messages.

To handle money settlements in Oracle FLEXCUBE, you have to:

Maintain Bank Identifier Codes (BIC)

Maintain Ultimate Beneficiary details

Maintain Settlement Preferences for a Customer/Module/Currency/Branch or for a combination of any of the entities.

2.2

Maintaining BIC Directory details

As part of setting up some basic information for the functioning of Oracle FLEXCUBE, you should maintain Bank Identifier Codes (BIC). You can define bank codes through the

‘BIC Code Details’ screen

. You can invoke this screen by typing ‘ISDBICDI’ in the field at the top right corner of the

Application tool bar and clicking the adjoining arrow button. If you are maintaining details of a new bank code, select

‘New’ from the Actions Menu in the Application toolbar or click new icon.

2-1

BIC codes can be maintained manually or uploaded from an external source onto Oracle

FLEXCUBE.

2.2.1 Specifying BIC Code details

BIC Code

You need to indicate the code by which the bank is identified by SWIFT. On indicating the Bank

Identifier Code, you should indicate the detailed name of the bank. If the bank is a customer of your bank, you can select the CIF ID assigned to the bank from the option list.

Once you select the CIF ID, the name of the bank will be displayed in the Bank Name field. If the bank is not a customer of your bank, you will have to manually enter the name and address of the bank.

The country information is captured to enable Mantas to analyse the transactions for possible money laundering activities.

For more details on Mantas, refer 'Mantas' interface document.

Relationship

You have to identify the kind of relationship that exists between your bank and the BIC entity.

2-2

Select any one of the following options to indicate the same:

No

– to indicate that the BIC Entity is not a customer of your bank

Mail

– select this option if the BIC entity is not a recognized SWIFT entity but an address internal to you bank. In such cases all correspondence directed to the particular BIC entity will be sent as mail messages.

Keys

– If a SWIFT /Telex connectivity exists between your bank and the bank for which you are maintaining details you can select this option. Subsequently, you will have to specify the SWIFT/Telex Key in the adjacent field.

SK arrangement

Indicate whether a SK arrangement exists between your bank and the BIC entity. If an arrangement does exist you can select the Yes option from the option list.

Sub-Type Code

Select the appropriate sub-type code to be mapped to the BIC. The adjoining option list offers the following factory-shipped codes:

BANK - SWIFT Member/Sub member

BEID - Business Entity Identifier

BROK - Brokers-Dealers

COOP - Co-operative Agreement with SWIFT

CSDS - Clearing Houses, Central Depositories

CUST - Subsidiary Providers of Custodian and Nominee Services

ETCP - Electronic Trade Confirmation Providers

EXCH - Recognized Exchanges

FUAD - Fund Administrators

IMIS - Investment Management Institutions

MCFI - Financial Institution in a MA-CUG

MCCO - Non-Financial Institution Participant in a MA-CUG

MONE - Money Brokers

NSFI - Non-Shareholding Financial Institutions

NSWB - Non SWIFT BIC's

PRXY - Securities Proxy Voting Agency

PSPA - Payment System Participants

REGI - Registrars and Transfer Agents

SSPA - Securities System Participants

TESP - Treasury ETC Service Provider

TRAD - Trading Institutions

TRAV - Travellers¿ Cheques Issuers

TRCO - Treasury Counterparty

TRUS - Trustees, Fiduciary Service Companies

ZZZZ - Undefined Institutions

Choose the appropriate one. In case of upload, the system automatically updates this field with the sub-type code corresponding to the BIC.

2-3

BEI Indicator

The system identifies whether the BEI status for the chosen subtype code is ‘Yes’ or ‘No’ from the backend maintenance in the ‘ISTM_SUBTYPE_CODE’ table. It checks this option whenever the status in the table for the subtype code is ‘Yes’. You cannot modify this field.

Payment Message

You can indicate whether your counterparty whose BIC Code details you are capturing is capacitated to receive payment messages in the MT 103 format. If so, enable the ‘Generate MT

103 as Payment Message’ option by checking the box.

However, the Counterparty bank will still receive the payment messages in the MT103 format if you do not enable the box ‘Generate MT 103 as Payment Message’

If you have chosen the MT 103 option, you can enable the MT 103 + format option if you would like to generate outgoing MT 103 messages in the MT 103 + Format. Enable the MT 103+ option by checking the ‘MT 103+ Preferred’ box.

You will be allowed to choose the MT 103+ option only if you have enabled the generation of

MT 103 messages as Payment Messages. Moreover, you should also ensure that you have also enabled this option:

For your bank branch in the Branch Parameters Maintenance

By choosing the Generate 103+ option for currency in the Currency Definition

For the product used by the contract, in the Product Preferences

The ‘other’ preferences that you need to specify for each BIC entity are as follows:

CUG Member

– enable this option by checking the box positioned next to this field to indicate that the BIC entity is a Closed User Group member

Update During Upload

Black-Listed

– this indicates that the BIC entity is also black listed

Remit Member - This indicates that the customer is registered with MT 103 Extended

Remittance Information Multi User Group.

Multi Customer Credit Transfer

This option is to indicate whether or not a Multi Credit Transfer Feature [MT102 support] exists between your bank and the BIC entity.

Maximum Size

Indicate the maximum size in bytes, agreed upon between the two parties for transmitting a

MT102 message. A null value in this field signifies that there is no limit set on the size of the message.

Whenever the queue exceeds the maximum size specified in the BIC maintenance, the system automatically splits the queue into multiple queues to contain the message within the specified limits.

Generate MT102+

Select this check box to process MT102+ messages. Selecting this check box also required the

‘Multi Customer Credit Transfer’ checkbox to be selected.

2-4

2.2.2 Request for Transfer

Generate MT101

This field indicates whether an MT101 can be sent/received from this BIC. Select this option to generate MT101 message.

Note: This is a primary selection criterion. A separate maintenance for agreements has to be maintained in the function ISDCCYRS to generate the MT101.

No of Transaction per Message

Here you can indicate the no of transactions to be included in an MT101 message. If you donot specify a value it will be defaulted to 10.

2.2.3 Maintaining BIC directories

Oracle FLEXCUBE allows you to store SWIFT BIC in the database. You can directly transfer data from the SWIFT BIC directories to the Oracle FLEXCUBE tables. You can view the uploaded data in the ‘BIC Summary’ screen.

You can invoke the

‘BIC Code Summary’ screen by typing ‘ISSBICDI’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

The query option is available on the following fields in this screen:

BIC Code

National ID (Only BIC Database plus)

CHIPS UID (Only BIC Database plus)

Institution name

2-5

Tag (To identify either FI or AM record type)

City

Location

Country Name

New BIC

New Branch Code

Modification

The BIC Code Summary screen operates as an upload table. The data is entered into Oracle

FLEXCUBE using these tables.

2.2.4 BICPlusIBAN support

Oracle FLEXCUBE supports the Upload of BICPlusIBAN directory.

BICPlusIBAN is a SWIFT directory that lists institution identifiers recognized by the financial industry, for example, Bank Identifier Codes, CHIPS UIDs, national clearing codes, and IBANrelated information. It also provides name and addresses of the corresponding entities.

BICPlusIBAN is used to identify correspondents and counterparties accurately, and to allocate the correct code when sending messages, thus improving Straight Through Processing (STP).

Initiators of cross-border payments within Europe are required to submit the BIC and IBAN codes to the receiver in order to benefit from reduced payment transaction charges.

You can invoke the ‘BIC Iban Maintenance Summary’ screen by typing ‘ISSIBANP’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

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

2-6

Unique Key for Record

Specify the unique key of the record in the file. This consists of ISO country code and sequential number of six digits.

I nvoke the ‘Iban Information Summary’ screen by typing ‘ISSISBAN’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

2-7

Invoke the

‘Iban Information Maintenance’ screen by typing ‘ISDISBAN’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Here you can specify the details of the following:

IBAN Country Code

Specify the ISO country code prefix in the IBAN.

2-8

IBAN Country Position

Specify the position of the country code in IBAN.

IBAN Country Code Length

Specify the number of characters of the country code in the IBAN.

IBAN Check Digits Position

Specify the start position of check digits in the IBAN

IBAN Check Digits Length

Enter the Number of check digits in the IBAN

Bank Identifier Position

Enter the Start position of bank identifier in the IBAN

Bank Identifier Length

Specify the Number of characters of bank identifier in the IBAN

Branch Identifier Position

Specify the Start position of the branch identifier in the IBAN (value is empty if the branch identifier is not applied in the country's IBAN format)

Branch Identifier Length

Specify the Number of characters of the branch identifier in the IBAN (value is 0 if the branch identifier is not applied in the country's BAN format)

IBAN National ID Length

Specify the Number of significant characters of the National ID value that are used by SWIFT to populate the IBAN NATIONAL ID, and that are sufficient to derive the IBAN BIC correctly.

This number can be different from (that is, smaller than) the length of the national bank/branch identifier defined in the IBAN Registry.

Note that as SWIFT refines its IBAN to BIC translation algorithms, this number may change from release to release.

Account Number Position

Specify the Start position of the account number in IBAN.

Account Number Length

Specify the Number of characters of account number in IBAN

IBAN Total Length

Specify the total number of characters of the IBAN.

2-9

2.2.5 Uploading BIC files

SWIFT allows you to upload the entire BIC file or individual records like Amendments (AM) and

File Instructions (FI) record files within the BIC upload file, on to the BIC directory. You can perform this through the ‘BIC Upload’ screen.

The BICPlusIBAN directory consists of the following files:

BI file (BICPlusIBAN Information)

IS file (IBAN Structure information)

The BICPlusIBAN directory should be used to

Translate beneficiary bank’s BIC into national (clearing, sort) code

Show banks’ participation in RTGS system

Show banks’ details (name, address & so on)

BICPlusIBAN Directory can also be used as an enquiry tool

SEPA Related:

Derive BIC from the IBAN, if missing

Validate IBANs and BICs

Validate IBAN-BIC combination in payments

On successful upload of BIC Plus IBAN, system populates the SWIFT BIC directory and the clearing codes automatically.

2.2.5.1 IS File Upload

This file forms the part of the BICPlusIBAN package. This contains information about the IBAN structure applicable in the countries.

IS File forms are stored in a new data store and are used for IBAN structure validations.

Invoke the

‘BIC Upload’ screen by typing ‘ISDBICPU’ in the field at the top right corner of the

Application tool bar and clicking the adjoining arrow button.

2-10

Here you can specify the following details:

Source Code

Specify the source from which you want to upload details. You can select the appropriate source code from the drop-down list displaying the following values:

BIC - Select this to upload the BIC file

CCH - Select this to upload the country-wise holiday file

BICPLUSIBAN

BICPLUSIBANIS

File Path

State the path in the database server where the uploaded file should be stored.

File Name

Specify a name for the uploaded file. The file name should bear the extension ‘.DAT’.

Click

‘Submit Params’ button and ‘Submit Batch’ button to start the upload process.

The file formats of these records are explained in the chapter titled ‘Annexure – A – File Formats’.

Refer this chapter for further details.

2.2.6 Operations on a BIC record

On an existing BIC code record, you can perform any of the following operations (if a function under the Actions Menu is disabled, it means that the function is not allowed for the record):

Apart from defining a new BIC code record you can perform any of the following operations on an existing record (if any function under the Actions Menu is disabled, it means that the function is not allowed).

Amend the details of a record

Authorize a record

2-11

Copy the details of the record

Close the record

Reopen the record

Delete the details of a record

Refer to the User Manual on Common Procedures for details of these operations.

It is assumed that the upload source contains details of all relevant BIC codes. The BIC records that are uploaded to Oracle FLEXCUBE should contain the following tags:

U - If records do not exist in the Oracle FLEXCUBE BIC directory, the same would be inserted. For a record that already exists, it will be updated with that of the BIC upload.

M - If there is no existing record in the Oracle FLEXCUBE BIC directory, the same would be inserted. Otherwise the record will be updated with the one in the BIC upload.

A - For an existing record in the Oracle FLEXCUBE BIC directory, an error will be logged and the upload will continue. If no records exist, then a new record will be updated with the one in the BIC upload.

D - If there is no existing record in the Oracle FLEXCUBE BIC directory, an error will be logged and the upload will continue. If there is any record existing, then it will be marked as ‘CLOSED’.

AM- For an existing record in the BIC file or AM file, BIC code would be renamed in the upload file

BIC addresses that have changed will be appropriately updated. Addresses bearing the tag D will be automatically deleted. New BIC records will be created for records that bear the tag N.

The network codes that a re marked for exclusion in the ‘BIC Upload Maintenance’ screen will not be uploaded.

The upload sequence is based on the modification tags in the BIC records. The sequence will occur in the following order:

Deletion

Modification

Addition

Unchanged

The file upload is processed in an asynchornous manner. The system prompts the user to check the logs.

Note:

The logs can be viewed by visiting Batch Operations -> Intra Day Batch -> Monitor (Fast Path:

BASIDMTR). The function field can be given as ISDBICPU% for searching the upload logs

Click

‘Exit’ or ‘Cancel’ button to exit the screen without initiating the upload process.

2-12

2.3

Maintaining Ultimate Beneficiary details

You can maintain the details related to the beneficiary of transaction through ‘Ultimate Beneficiary

Maintenance’ screen. You can invoke this screen by typing ‘ISDUTBEN’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. If you are maintaining details of a new beneficiary, select ‘New’ from the Actions Menu in the Application toolbar or click new icon.

You can specify the following details in this screen:

Beneficiary Name

Specify the name of the ultimate beneficiary for whom you are maintaining details. You can maintain several settlement combinations for an Ultimate Beneficiary

Beneficiary Account

Specify the account number of the ultimate beneficiary to which funds need to be credited. The account number should be a valid account with the bank that you specify in the BIC Code field.

Beneficiary Address

Specify the address of the ultimate beneficiary. Each row can contain a maximum of thirty five alphanumeric characters.

Country Code

Specify country code of the ultimate beneficiary for whom you are maintaining details or select the country code from the option list provided.

If the country code is Spain, then the system applies CCC validation on the beneficiary account. If the country code is not Spanish, then the system applies IBAN validation.

2-13

Receiver Bank Identification Code

Specify the Bank Identification Code (BIC) of the receiver bank or select the BIC from the option list provided.

Account With Institution Bank Identification Code

Specify the Bank Identification Code (BIC) of the Account with Institution bank or select the BIC from the option list provided.

Customer Information File Number

Specify the CIF number of the ultimate beneficiary for whom the details are being maintained or select the CIF number from the option list provided.

Advice to Beneficiary By

You can indicate the mode of sending advice to beneficiary here. The following options are available:

Fax Number

Specify the fax number of the ultimate beneficiary for whom you are maintaining details.

Mobile Number

Specify the mobile number of the ultimate beneficiary for whom you are maintaining details.

Email Address

Specify the email address of the ultimate beneficiary for whom you are maintaining details.

You can specify only one of the options among fax number, mobile number and e-mail address.

2.4

Maintaining multi mode settlement details

Multimode settlement is applicable only for Consumer lending module of Oracle FLEXCUBE. All settlements are, typically, made using accounts. However, in Oracle FLEXCUBE, settlements can be done through different modes in addition to the account level settlement. The different modes can be:

Cash

Instruments

External Accounts

Pay Orders

Internal Cheque

Clearing

Debit Card

Credit Card

You can also make settlements using a combination of any of the modes mentioned above i.e. part by cash, part by cheque and the rest by credit card or any other combination of your choice.

2-14

You can capture the different modes of settlement through the ‘Multimode Settlement

Maintenance

’ screen. You can invoke this screen by typing ‘ISDSRCMD’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. The modes are captured for a Source, Module, Product and Currency combination.

The following details have to be captured in this screen:

Source

Oracle FLEXCUBE interfaces with other external systems of your bank. Transactions originating in external systems may require to be uploaded into Oracle FLEXCUBE for further processing.

For maintaining the settlement modes for such transactions, you have to indicate the source code of the external system here. The source codes of all external systems are available in the optionlist provided from where you can make the appropriate selection.

You may use the Source Code ‘Oracle FLEXCUBE’ to maintain settlement modes for transactions originating in Oracle FLEXCUBE.

Module

You have to specify the module of the transactions that have to be settled using different modes.

The value of this field is defaulted to CL (Consumer Lending). You cannot modify this value.

Product

Here, you have to indicate the product of the transactions that have to be settled using different modes. The option-list will display the different products available under the selected module. You may also use the wild character ‘****’ as the product code. The system will use this information if settlement mode maintenance is not available for a product under the selected module.

Currency

You have to specify the currency of the transactions that have to be settled using different modes.

You may also use the wild character ‘***’ for a currency. This will be used if maintenance for a specific currency is not available.

2-15

For the above combination of Source, Module, Product and Currency, you can maintain multiple settlement modes and the associated details given below:

Setl Mode

For the selected combination, you have to specify the settlement mode. The list of available modes is predefined in the system and you can select a mode from the drop-down list. Since CL is the module used for the multimode settlement the different modes available are:

CASA

Cash/Teller

Instrument

External Account

Electronic Pay Order

Internal Cheque

Clearing

Debit Card

Credit Card

Pay Setl Ac

For the selected settlement mode, you have to specify the Suspense/Control GL into which the transactions (that satisfy the selected combination) need to pass the accounting entry. This GL will be used only when the bank is making a payment. The settlement account gets credited in this case.

Pay Setl Prod

For the selected settlement mode, if the originating transaction results in a linked transaction, you need to specify the product that should be used to create the linked transaction. This product will be used when the settlement account gets credited. For example, if the settlement mode is ‘DD’, you have to specify the product code (i.e. the DD instrument type) for creating the corresponding instrument transaction in Oracle FLEXCUBE.

Recv Setl Ac

Just as you specify the pay settlement account for the mode selected, you also have to indicate the Suspense/Control GL into which transactions (that satisfy the selected combination) need to pass the accounting entry when the bank receives a payment. The selected account gets debited in this case.

Recv Setl Prod

If the originating transaction (payment received) results in a linked transaction, you have to specify the product to be used to create the linked transaction. This product will be used when the settlement account gets debited. For instance, if the settlement mode is ‘External Cheque’, you have to specify the clearing product to be used for creating the clearing transaction.

For details on multi mode settlement processing, refer the heading titled ‘Processing settlements’ in this chapter.

2-16

2.5

Capturing Settlement Preferences for a Customer

You can maintain the settlement preferences of a customer or a bank in the

‘Settlement

Instructions Maintenance

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

Indicating preferences for an entity means defining the settlement accounts and a detailed settlement route comprising the correspondent accounts and the intermediaries through which payment is to be routed. (The party information you can capture adheres to SWIFT standards.).

You can maintain the following basic settlement preferences for an entity (Customer /BIC), module, currency, product, Sequence Number and branch combination.

The Pay (out) Account, Branch and Currency

The Receive Account (for incoming payments), Branch and Currency.

If a Cover is required to be sent for SWIFT messages

If the charge (for the message) is to be borne by the bank or the beneficiary, or shared between them

The charge account, which will be used as the default account for all charges during contract input

If a receive notice (MT 210) has to be generated for money settlements made in a specific currency

Counterparty Type

The Counterparty Type can either be CIF or BIC depending on whether your bank has an accounting relationship with the party for whom the instruction is being maintained or whether it only has a SWIFT messaging relationship. If the counterparty is a CIF in Oracle FLEXCUBE, you will have to select CIF as the party type and choose the relevant CIF ID in the adjacent field.

2-17

However, if the entity is not an actual customer of your bank but you would be sending/receiving payment messages to/from that party, you will have to choose BIC as the counterparty type and specify the counterparty’s address as well. As a result, you will need to identify the preferred

Nostro/ Vostro accounts for that currency and BIC code combination.

Note the following:

If you opt to generate receive notices for settlements made in all currencies, involving all counterparties, and transactions in all modules of Oracle FLEXCUBE, an MT 210 will automatically be generated for any money settlement made by your branch.

If you are defining settlement instructions for a customer related to the FT module you have to indicate the charge account, which will be used as the default account for deducting all charges involved in processing the FT.

While processing an FT for the customer the appropriate charge account is picked up depending on the customer, currency and branch processing the FT.

In addition, you can maintain the details of the various intermediaries involved in payments and receipts. The preferences maintained for an entity determine the manner in which money settlements are made on behalf of the entity.

Counter Party

You can maintain settlement instructions for all the customers or for specific customers only.

From the option list select the specific customer number or choose the ALL option

Module

You can maintain different settlement instructions for different products. If you choose Module as

‘ALL,’ then the Product must also be chosen as ‘ALL’. If you choose a specific module for maintaining settlement instructions, then you can choose any Product available under the module from the option list provided. You can also choose ‘All’ to maintain settlement instructions for all products under the selected module.

Product Code

Indicate a specific product code or choose All from the option list. However, if you have chosen

All in the Module field, this field will be defaulted to ALL. You will not be allowed to change this.

Currency

You can maintain settlement instructions for a particular currency or for all the currencies From the option list select the particular currency code or choose the ALL option.

For customer account transactions in foreign currency, where charge needs to be debited in local currency, you need to maintain a record for the combination of branch, currency, module, product and customer, where the currency specified is the local currency used for settling charges.

For more details, refer ‘Building Charge Rules’ section in Charges and Fees user manual and

‘Building the Commission Rule’ section in commission user manual.

Branch

You can maintain settlement instructions for all the branches or for a particular branch. From the option list select the particular branch code or choose the ALL option.

2-18

Payment By

Indicate the method of payment for both Outgoing as well as Incoming Payments, for a Branch,

Account and Currency combination. The following options are available:

Instrument (settlement is done through a Check, MCK etc.)

Message (payment is made by means of a SWIFT Message)

Clearing (the transaction is a local payment transaction and the settlement is routed through the Clearing House of the bank)

You can indicate the payment method as ‘Clearing’ only,

If the payment currency is the local currency of the branch

If it is one of the clearing currencies defined for the branch

If you have selec ted ‘ALL’ in the currency field

No payment message will be generated for settlements routed through a Clearing House.

You can select ‘Payment By’ as ‘Instrument’, to ensure the payment by Instrument in SI settlements screen and then the system would look for the instrument type.

Charge Details

Specify whether charges for the message are to be borne by the bank (ourselves) or the beneficiary, or will be shared. This information is inserted in Field 71A of an MT103 message involving the combination for which settlement instructions are being maintained. You can select one of the following options:

Ourselves

– It is displayed as ‘OUR’ in the message and it indicates that all transaction charges are to be borne by the ordering customer.

Beneficiary

– It is displayed as ‘BEN’ in the message and it indicates that all transaction charges are to be borne by the beneficiary customer.

Shared

– It is displayed as ‘SHA’ in the message and it indicates that the transaction charges on the Sender’s side are to be borne by the ordering customer and the transaction charges on the Receiver’s side are to be borne by the beneficiary customer.

Cover Required

This indicates whether the payment has to be sent with a cover message. Check this box to enable this option.

Cover By

If you have indicated that a cover is required for payments involving the customer, then, in this field, you can indicate whether the cover is through messaging or through local clearing.

Accordingly, you can choose the required option in this field.

If you indicate that cover is through messaging, and the payment is through local clearing, you need to maintain the local clearing counterparty details in the Local Clearing tab.

If you indicate that cover is through local clearing, you need to maintain the cover details in the

Cover Details tab.

2-19

2.5.1.1 Maintaining settlement instructions for CLS deals

When maintaining settlement instructions for CLS deals, you should specify the module as ‘FS’

(FX Settlements). This will indicate that they are meant exclusively for CLS deals.

The p ay and receive accounts specified for the settlement instructions will be used as the ‘Control

Accounts’ for CLS deals.

Refer the ‘Continuous Linked Settlements’ chapter of the Foreign Exchange User Manual for details on the following:

Maintaining settlement instructions for CLS deals,

Other maintenances required to be CLS compliant

The processing involved in the settlement of CLS deals in Oracle FLEXCUBE

2-20

2.5.2 Capturing Details of Parties Involved in Payments

Before funds actually reach the Ultimate Beneficiary of a payment, it may have to pass through several other banks or parties. You can capture details of the parties involved in a payment in the

‘Pay Parties’ sections of the ‘Settlement Instructions Maintenance’ screen.

These screens contain fields that mark possible routes of a payment.

Intermediary Reimbursement Institution

An ‘Intermediary Reimbursement Institution’ is the financial institution between the Sender’s

Correspondent and the Receiver’s Correspondent, through which the reimbursement of the transfer takes place.

Country

Specify the country of the intermediary reimbursement institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Intermediary

The ‘Intermediary’ in a payment refers to the financial institution, between the ‘Receiver’ and the

‘Account With Institution’, through which the transfer must pass.

The Intermediary may be a branch or affiliate of the Receiver or the account with Institution, or an entirely different financial institution. This field corresponds to field 56a of a SWIFT message.

You can either enter the:

ISO Bank Identifier Code of the bank

The Name and address of the Bank

Country

2-21

Specify the country of the intermediary institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

The country information is captured to enable Mantas to analyse the transactions for possible money laundering activities.

For more details on Mantas, refer 'Mantas' interface document.

RTGS Payments

If the settlement chosen is one of the RTGS Nostro that is, RTGS outgoing Nostro account in case of Outgoing customer and Bank transfer and RTGS incoming Nostro in case of outgoing

Direct Debit transfer then the system will check this check box as per the validations done in

RTGS Network. You cannot change this value.

RTGS Network

If in a RTGS Network the accounts are maintained as ‘Pay account’ or ‘Receiver Account’ while saving the settlement instruction, then a set of validations will be performed as mentioned below:

For Pay message, system will validate whether the intermediary (if intermediary is not present, the Account with Institution (AWI) will be validated and if the AWI is also not present then receiver will be validated) is a RTGS participant.

For Pay+ Cover message, system will validate if the receiver correspondent is a RTGS network participant.

If the above conditions are satisfied, the RTGS Network will be updated and the system will check

RTGS Payments check box.

Receiver’s Correspondent

The ‘Receiver’s Correspondent’ is the branch of the Receiver, or another financial institution, at which the funds will be made available to the Receiver.

2-22

Receivers Correspondent

This field corresponds to field 54a of S.W.I.F.T. Enter the branch of the Receiver or another financial institution at which the funds will be made available to the Receiver. You can enter any one of the following:

ISO Bank Identifier Code of the bank

Th e branch of the Receiver’s Correspondent

Name and address of the Receiver’s Correspondent

Country

Specify the country of the branch of the receiver / institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Sender to Receiver Information

The sender to receiver information maintained in the settlement instructions can be defaulted in the field 72 in the confirmation messages. The adjoining option lists displays the following values:

//

/ACC/ - Account with Institution

/BNF/ - Beneficiary

/BUP/ - Backup Payment

/CHEQUE/ - Pay only by cheque

/CLSTIME/ - CLS Time

/INS/ - Instructing Institution

/INT/ - Intermediary

2-23

/MANPAY/ - Mandated Payment

/PHON/ - Deal by Phone

/PHONBEN/ - Contact beneficiary by phone

/PHONIBK/ - Contact intermediary by phone

/RCB/ -

Receiver’s correspondent

/REC/ - Receiver

/REJT/ - /REJT/

/RETN/ - /RETN/

/TELE/ - /TELE/

/TELEBEN/ - /TELEBEN/

/TELEIBK/ - /TELEIBK/

/TSU/ - Trade Services Utility transaction

/BROKER/ - Broker negotiating the contract

/ ELEC/ - Deal has been arranged via an electronic means

/TELEX/ - Deal by TELEX

/TIME/ - Time of transaction execution

/VENU/ - Venue of transaction execution

If you choose, ‘/TSU/’, the code placed between slashes ('/') must be followed by the invoice number, a slash ('/') and the amount paid.

Account With Institution

An ‘Account with Institution’ refers to the financial institution, at which the ordering party requests the Beneficiary to be paid. The Account With Institution may be a branch or affiliate of the

Receiver, or of the Intermediary, or of the Beneficiary Institution, or an entirely different financial institution.

This field corresponds to Field 57A of a SWIFT message. You can enter one of the following:

ISO Bank Identifier Code of the bank

Branch o f the Receiver’s Correspondent

Name and address of the Receiver’s Correspondent

Other identification codes (for example, account number)

Country

Specify the country of the account with institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one

The country information is captured to enable Mantas to analyse the transactions for possible money laundering activities.

For more details on Mantas, refer 'Mantas' interface document.

Receiver

You can specify the final Receiver as apart from the Account With Institution if the Ultimate

Beneficiary desires that the payment message should be sent there. If this is not maintained, the

Account With Institution becomes the default Receiver.

2-24

You can also capture the Sender to Receiver Information in this screen.

For more details relating to specific parties, please refer to the SWIFT manuals.

ERI Currency

For every Counterparty and 'In' Currency (combination) for which you maintain settlement instructions, you can define an Euro Related Information (ERI) Currency. The ERI Currency can be:

'In' currency

Euro

This is used 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 an ERI currency.

The ERI Currency that you specify for a Counterparty and 'In' currency (combination) will default in the ERI CCY field in the Settlements Message Details screen.

Settlement through an instrument or message

When the actual settlement event for a contract (involving the entity) takes place, the payment and receive message details are updated in a message hand-off table. The Messaging system picks up the details from this table, and based on the formats set up, generates the messages.

2.5.3 Capturing Details of Parties Involved in Receipts

Depending on the route funds take when you receive (incoming) payments, you can maintain

Intermediary and Beneficiary Institutions in the ‘Receive Parties’ section of the ‘Settlements

Instructions Maintenance

’ screen.

2-25

Receiver Intermediary

This field corresponds to field 56a of S.W.I.F.T. Specify details of the financial institution between the ‘Receiver’ and the ‘Account With Institution’, through which the amount must pass. The

Intermediary may be a branch or affiliate of the Receiver or of the Account With Institution, or an entirely different financial institution.

In this field you can choose to enter the:

ISO Bank Identifier Code of the bank

Name and address of the Bank

Country

Specify the country of the receiver’s intermediary. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Beneficiary Institution

This field corresponds to field 58a of S.W.I.F.T. Enter details of the institution in favor of which the payment is made. It is in reality the bank, which services the account of the ultimate beneficiary.

You will be allowed to make entries into this field only for Bank transfers (MT 200 or MT 202). In this field you can enter either the:

The ISO Bank Identifier Code of the Beneficiary Institution

The Name and Address of the Beneficiary Institution

Country

Specify the country of the beneficiary institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

2-26

Account with Institution

Enter the details of the account with institution.

The system applies CCC or IBAN validation to Account wit Institution depending upon the country code selected.

Note the following:

If you have already maintained this information in the Settlement Instructions Maintenance screen, then it will be picked up and reflected here.

The country information is captured to enable Mantas to analyse the transactions for possible money laundering activities.

For more details on Mantas, refer 'Mantas' interface document.

2-27

2.5.4 Capturing Cover details

The Cover details are defaulted from the

‘Contract Online’ screen only for Outgoing Customer

Transfers with Cover.

You can specify the following details:

Country

Specify the country of the beneficiary institution for cover. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

2.5.5 Maintaining Local Clearing Details and Cover Details for Customer

Settlement Instructions

When you specify settlement instructions for a customer, you can indicate whether payment for local currency transactions is to be effected via messaging or over the local clearing network. You can also indicate whether a cover is required for payment, and whether the cover is through messaging or over the local clearing network.

You can specify these details in the Settlement Instructions screen. In the Payment By field, indicate the mode of payment, either Message or Clear Details; and in the Cover By field, indicate the mode through which cover must be available.

If you indicate payment over a clearing network, you must specify the account details of the external counterparties (both pay and receive accounts) in the

‘Clear Details’ tab in the

‘Settlement Instructions Maintenance’ screen. In case you choose the option ‘Clearing’, then a PC contract will be automatically created. This PC contract will be created based on the appropriate transaction currency based on the Clearing Network that is maintained as part of the Settlement

Instructions.

2-28

For the counterparty details, you can specify the bank code, account and account name.

External Counterparty Pay Details

The description of the selected bank, where the external counterparty account resides, is displayed here. Specify the external account number. If the country code is Spain, then the system applies CCC validation on the external pay account. System does not apply IBAN validation when the country code is Non Spanish, as external pay account does not support 24 characters.

External Counterparty Receive Details

The description of the selected bank, where the external counterparty account resides, is displayed here.

Specify the external account number. If the country code is Spain, then the system applies CCC validation on the external receive account. System does not apply IBAN validation when the country code is Non Spanish, as external receive account does not support 24 characters.

If you indicate cover for payment via the local clearing network, you must specify the account details of the cover party, in the

‘Cover Details’ tab in the ‘Settlement Instructions Maintenance’ screen.

2-29

For the cover party account details, you can specify the bank code, account and account name.

The following scenarios are possible:

Cover

Required

Cover By Payment By Local Clearing

Counterparty Details?

Cover Details?

Yes

Yes

Message

Local

Clearing

Message

Message

No

No

No

Yes

No

No

Message

Local

Clearing

No

Yes

No

No

Clearing Network for Local Clearing in Settlement Instructions

You can specify a clearing network during settlement instruction maintenance for the Pay Leg and the Cover details. This will be defaulted as part of Settlement pick-up during Contract input and used subsequently while generating a PC Contract.

The Counter-party name shows the list of Bank Codes for Cover Transfer and Bank Transfer. The system will validate that the Bank Code Type for both the Counter-party name and Counter-party

Bank Code is the same. For Customer transfers, this would be a user enterable field.

2-30

2.5.6 Specifying the default MT 103 details

You can define the default values for fields in MT 103 messages that are generated in respect of contracts involving the customer. When a contract is entered for the customer in any module, the values that you maintain here will be defaulted for MT 103 generation in respect of the contract.

You can maintain these details in the

‘Other Details’ tab in the ‘Settlement Instructions

Maintenance’ screen.

You can maintain the default MT 103 values for the following fields:

Bank Operation Code

You can indicate the bank operation code that will be inserted in Field 23B of the MT 103 message. The options available are SPRI, SSTD, SPAY and CRED.

Note that if the Bank Operation Code contains SPAY, SSTD or SPRI, the following validations will be done:

C11: If account with institution is used with D option, then party identifier is mandatory.

(Either Clearing code or account has to be specified in the account line).

C12: Account is mandatory in field 59

Instruction Code

You can indicate the Instruction code that will be inserted in Field 23E of the MT103 message.

The options available are CHQB, TELE, PHON, PHOI, REPA, INTC, TELI, SDVA, PHOB, TELB,

HOLD, CORT and BONL.

Instruction Code Description

You can specify the additional information, if any, which would be inserted to qualify the

Instruction Code in Field 23E of the MT103 message. The instruction code description can only be maintained for the instruction codes PHON, PHOB, PHOI, TELE, TELB, TELI, HOLD or

REPA.

2-31

For instance, if the Instruction Code is REPA and the description is

‘Repayment’ then the text

‘REPA/Repayment’ is inserted in Field 23E.

Transaction Type

You can indicate the Transaction Type that will be inserted in Field 26T of the MT103 message.

Regulatory Reporting Details

You can indicate the Regulatory Reporting Details that will be inserted in Field 77B of the MT103 message.

Charges Details

You can indicate whether charges for the message are to be borne by the bank (ourselves) or the beneficiary, or will be shared. You can specify this in the Charges Details section, in the main

Settlement Instructions screen.

This information is inserted in Field 71A of the MT103 message.

2.5.6.1 Specifying SWIFT RUR Account Details

Ordering Institutions

Specify the ordering institution in this option. The same is defaulted in the Contract level and based on the value captured here, field 52D is populated

Intermediary Account

Specify the intermediary account in this option. The same is defaulted in the Contract level and based on the value captured here, field 56D is populated

Account with Institution

Specify the account with institution. The same is defaulted in the Contract level and based on the value captured in Account with Institution; account number for 57D field is populated.

Beneficiary Institution

Specify the beneficiary with institution. The same is defaulted in the Contract level and based on the value captured here, field 59D is populated.

For more details refer section ‘Transliterating Payment Messages’ in chapter ‘Contract’ of ‘Funds

Transfer’ User Manual

2.6

The Sequence in which Settlement Instructions are resolved

While processing contracts in Oracle FLEXCUBE, the settlement instructions maintained are resolved in the following sequence:

Level Counterparty CCY Module Branch

1 Counterparty CCY MOD Branch

2 Counterparty CCY Mod ALL

2-32

14

15

16

10

11

12

13

8

9

6

7

4

5

Level Counterparty CCY Module Branch

3 Counterparty CCY ALL Branch

Counterparty

Counterparty

CCY ALL

ALL MOD

ALL

Branch

Counterparty

Counterparty

Counterparty

ALL

ALL

ALL

ALL

MOD

ALL

ALL

CCY MOD

ALL

Branch

ALL

Branch

ALL

ALL

ALL

ALL

ALL

ALL

ALL

CCY MOD

CCY ALL

CCY ALL

ALL

ALL

ALL

ALL

MOD

MOD

ALL

ALL

ALL

Branch

ALL

Branch

ALL

Branch

ALL

2.7

Processing Settlements

The Settlement details for a contract or deal get defaulted based on the maintenance of settlement instructions for the Customer/BIC code involved in the transaction. To invoke the

‘Settlement Details’ screen, click ‘Settlement’ button in the Contract Main screen of a module.

2-33

By default the settlement details of all components of a contract which affect a customer type of account (the Role Types can be Customer, Remitter, Beneficiary for all the events associated to the product for which the Role-to-Head mapping has not been provided to the product associated with the contract) are displayed in this screen.

Example

As per the maintenance that you have done for a Product the following accounting entries will be posted during the initiation of a contract.

Accounting Role Amount Tag Dr/ Cr Indicator

ASSETGL PRINCIPAL Debit

CUSTOMER PRINCIPAL Credit

To achieve this, in the Role to Head mapping sub-screen of the Product Definition screen you would have mapped the Accounting Role ASSETGL to an actual internal leaf GL of your Chart of Accounts. However, you would not have maintained such a mapping for CUSTOMER since this is a role whose value gets defined at the contract level based on the counterparty involved in the contract.

While processing a contract you can modify the following information pertaining to Settlements:

Account details (details about the accounts involved in the contract or deal; that have to be either debited or credited in your branch)

Message details (payment details -- whether settled by an instrument or a messaging service such as SWIFT)

Party details (details about the various parties/banks involved in the transfer of funds to the

Ultimate Beneficiary).

Other Details, (the default values for fields in MT 103 messages for the contract)

For ‘Charge’ components, the system automatically picks up the settlement account maintained for the combination of the customer and settlement currency.

2-34

2.7.1 Capturing Account Details

In the Settlement Instructions screen you would have maintained the settlement accounts for an entity, module, currency and branch combination.

While processing a contract, these details will be defaulted to the Settlement sub-screen of the contract main screen. You have the option of changing any or all of the settlement accounts while processing a contract.

2.7.1.1 Account Details

The account details that get defaulted include the following:

Component and its Currency

Payment Account and its Currency

Branch of your bank to which the account belongs

Note the following:

If settlement instruction is not defined for the customer, than system will always default the

Nostro accounts based on settlement instruction set.

Change the settlement account branch and settlement account for charge component in case change or waiver at contract level.

Original Exchange Rate

If the component currency is different from the account currency, the system requires an exchange rate for the conversion. The components of the final exchange rate used for conversion are:

The Base Rate

– this is defaulted from the exchange rate that you have maintained for the currency pair involved. It is computed as Mid Rate +/- Spread (depending on whether it is the Buy Spread or the Sell Spread).

The Customer Spread - the spread that you have maintained for the specified

Counterparty, Currency Pair and Tenor combination in the Customer Spread

Maintenance screen is picked up and applied for the customer involved in the deal.

2-35

The final exchange rate = Base Rate +/- Customer Spread (depending on whether it is a Buy or a

Sell deal).

If Customer Spread details for a specific counterparty (for the currency pair) are unavailable, the System looks for the customer spread maintained for the wildcard ALL entry. If even that is not available, then the Customer Spread defaults to zero.

The method of spread definition, whether percentage or points is also displayed.

If you have specified an account that uses an account class that is restricted for the product, an override is sought when you attempt to save the contract.

Exchange Rate

For transactions involving any relationship pricing benefit scheme, the customer specific exchange rate derived by adding the original exchange rate and the customer spread maintained for the relationship pricing scheme, gets displayed here.

If Relationship Pricing is not applicable, Exchange Rate will be the same as the Original

Exchange Rate.

For more details on customer specific exchange rates, refer the section titled ‘Specifying Pricing

Benefit Details’ in Relationship Pricing user manual.

Rate Code

Specify rate code by selecting appropriate rate code from selection list. Following values are available:

Buy

Sell

Mid

In case of charges, if charge currency and settlement currency are different, system applies mid rate.

Customer Spread

This defaults from your specification of tenor-wise spread for the relevant Currency Pair in the

Customer Spread Maintenance screen. You can change this for a specific contract.

ERI Currency and ERI Amount

SWIFT messages (MT103/MT202) generated towards settlement can furnish the value of the settlement amount in both the settlement account currency, and a Euro Related Information (ERI) currency of your choice. If you opt to furnish the ERI value of the amount, you have to enter the following in this screen:

The ERI currency

The ERI Amount

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 (in the Currency Maintenance screen).

2-36

Gen Message

Enable this option if a payment messages has to be generated for the settlement instruction.

Netting

In addition to maintaining a netting agreement for each counterparty, you have to specify whether or not the contract is under the netting agreement for each contract involving the counterparty.

Check this box to indicate that you would like to enable the Netting option for the various components (Amount Tags) involved in the transaction. These components could be commission, interest, tax, charges etc.

Cross-currency Settlements of FX 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’.

Example

Assume you enter into the following foreign exchange deal. You sell 100,000 FRF against USD.

The scenario:

You specify the exchange rate: 1 USD = 5.2 FRF

The bought amount is therefore: 19230.769 USD

The settlement account is in EUR

The exchange rate between EUR/FRF: 1 EUR = 6.475 FRF

Since FRF is an ‘In’ currency, you can settle the sell leg of the deal through EUR (in this example). The settlement amount would be EUR 15444.015.

Suppressing Settlement Messages

Settlement messages, defined for components that fall due, will be generated automatically when the settlement actually happens for the respective component. You can suppress the generation of the settlement message, defined for a component, by clearin g the check box in the ‘Gen

Message’ field.

If a component is to be paid the credit account chosen becomes the pay account. Similarly, if a component is to be received the debit account chosen becomes the receive account in the settlement maintenance.

2.7.2 Capturing Message Details for a contract

A contract can either be settled through an instrument or a Messaging service (such as SWIFT).

The details of the instrument or message have to be specified in the

‘Message Details’ screen.

The message details that you specify will apply only for messages generated through SWIFT.

The type of SWIFT message that is generated depends on the parties involved in the contract.

2-37

2.7.2.1 Account Details

Payment By

Indicate the method of payment for both Outgoing as well as Incoming Payments, for a Branch,

Account and Currency combination. The following options are available:

Instrument (settlement is done through a Check, MCK etc.)

Message (payment is made by means of a SWIFT Message)

Clearing (the transaction is a local payment transaction and the settlement is routed through the Clearing House of the bank)

You can indicate the payment method as ‘Clearing’ only,

If the payment currency is the local currency of the branch

If it is one of the clearing currencies defined for the branch

If you have selected ‘ALL’ in the currency field

No payment message will be generated for settlements routed through a Clearing House.

Depending on the method in which you want to settle the contract, you should specify either

Instrument or Message details.

Instrument details

If you opt to settle a contract with an instrument, you should specify the type of instrument that you would use. For example, you could settle a contract using a Manager’s Check, a Check or a

Demand Draft. You should also specify the number that identifies the instrument. This number will be printed on the instrument.

If the settlement is through an instrument, you cannot specify party details.

Settlement through instruments is a feature applicable only for the Funds Transfer module of

Oracle FLEXCUBE.

2-38

Details of Charges

In this section you can maintain details of the party who will bear the charges incurred in processing the transaction. It could be either:

Remitter

– All Charges

Beneficiary

– All Charges

Remitter

– Our Charges

Note that in FT Module,

‘Details of Charges’ is selected on the basis of value selected in

‘Charge Bearer’ field in the ‘Other Details’ tab.

Also note the following:

Remitter

– All Charges - Corresponds to ‘OURS’ in Field 71 A of SWIFT MT 103 / 103+.

Beneficiary

– All Charges - Corresponds to ‘BEN’ in Field 71 A of SWIFT MT 103 / 103+.

Remitter

– Our Charges - Corresponds to ‘SHA’ in Field 71 A of SWIFT MT 103 / 103+.

Clearing Network

Cover details for local clearing will capture Clearing Network. This clearing network will be defaulted during Contract Input and be used subsequently for PC Product resolution while generating a PC contract.

2.7.2.2 Message details

For a SWIFT message, you should specify:

Whether a Cover has to be sent to the Reimbursement Bank, along with the payment message to the receiver

Bank to bank payment details, (these can be in the form of instructions or additional information to any of the parties involved in the contract)

Any Sender to Receiver information

Sender to Receiver Information

This could be instructions or additional information for the Receiver, Intermediary, Account With

Institution or Beneficiary Institution.

This field corresponds to field 72 of the S.W.I.F.T. message. The format of the message depends on the type of S.W.I.F.T. message that is generated. Refer to the S.W.I.F.T. manual for details on the format of the message and the code words to be used.

Payment By

Select the payment by option. Following are the options available:

Message

Instrument

Clearing

Details of Payment

Here you can specify information, from the Ordering Party to the Beneficiary Customer, about the reason for the payment.

2-39

This field can contain reference numbers, invoice numbers or any other details, which will enable the Beneficiary to identify the transaction. This information is to be passed through the payment chain to the Beneficiary.

This field corresponds to field 70 of S.W.I.F.T. Refer to the S.W.I.F.T. manual for details on the code words and the format of the message you can input.

Transfer Type

You can specify whether the Transfer Type should be:

Bank Transfer

Customer Transfer

Bank Transfer for own A/c

Direct Debit Advice

MCK

Customer Transfer with Cover

None

Banking Priority

Select the priority of the payment messages from the drop down list. The options available are:

Highly Urgent

Urgent

Normal

The default value is Normal.

RTGS Payments

If the settlement chosen is one of the RTGS Nostro that is, RTGS outgoing Nostro account in case of Outgoing customer and Bank transfer and RTGS incoming Nostro in case of outgoing

Direct Debit transfer then the system will check this check box as per the validations done in

RTGS Network. The user cannot change this value.

RTGS Network

If in a RTGS Network the accounts are maintained as ‘Pay account’ or ‘Receiver Account’ during the save of settlement instruction, then a set of validations will be performed as mentioned below:

For Pay message, it will validate the intermediary (if intermediary is not present, the Account with

Institution (AWI) will be validated and if the AWI is also not present then receiver will be validated) is a RTGS participant.

For Pay+ Cover message, it will validate that a receiver correspondent is a RTGS network participant.

If the above conditions are satisfied, the RTGS Network will be updated and the system will check

RTGS Payments check box.

2-40

2.7.3 Capturing Party Details

When you settle a contract, funds may have to pass through a series of banks before it actually reaches the Ultimate Beneficiary. In the Parties screen, you can capture details of all parties involved in a contract.

2.7.3.1 Parties

These screens contain fields that can capture details of all the possible parties through whom the funds involved in a contract can pass. Depending on the type of contract you are processing, and the number of banks involved, you should enter details in these screens.

Intermediary Reimbursement Institution

An Intermediary Reimbursemen t Institution is the financial institution between the Sender’s

Correspondent and the Receiver’s Correspondent, through which the reimbursement of the funds will take place.

Country

Specify the country of the intermediary reimbursement institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Intermediary

The Intermediary in a contract refers to the financial institution, between the Receiver and the

‘Account with Institution’, through which the funds must pass. You have to specify the

Intermediary Institution Account number.

The Intermediary may be a branch or affiliate of the Receiver or the

‘Account With Institution’, or an entirely different financial institution. This field corresponds to field 56a of SWIFT

Here you can enter either the:

ISO Bank Identifier Code of the bank

Name and address of the Bank

2-41

Country

Specify the country of the intermediary institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Receiver’s Correspondent

The Receiver’s Correspondent is the branch of the Receiver or another financial institution at which the funds will be made available to the Receiver. This field corresponds to field 54a of

SWIFT. You can enter one of the following:

ISO Bank Identifier Code of the bank

The branch of the Receiver’s Correspondent

Name and address of the Receiver’s Correspondent

Country

Specify the country of the receiver’s correspondent. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Account with Institution

An Account with Institution refers to the financial institution, at which the ordering party requests the Beneficiary to be paid. The

‘Account with Institution’ may be a branch or affiliate of the

Receiver, or of the Intermediary, or of the Beneficiary Institution, or an entirely different financial institution. This field corresponds to field 57a of SWIFT. You can enter one of the following:

ISO Bank Identifier Code of the bank

The branch of the Receiver’s Correspondent

Name and address of the Receiver’s Correspondent

Other identification codes (for example, account number)

Account Number of Account with Institution

If no selection is made for Account with Institution, all beneficiaries will appear for selection in the option list for Ultimate Beneficiaries in the Parties tab 2 screens. If a particular Ultimate

Beneficiary is selected in Parties tab 2, then the Account with Institution for the selected ultimate beneficiary will appear by default in the AWI field in the Parties tab 1 screen.

Country

Specify the country of the account with institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

The country information is captured to enable Mantas to analyse the transactions for possible money laundering activities.

For more details on Mantas, refer 'Mantas' interface document.

Receiver of Cover

Specify the details of the Receiver of the cover message, which can be any one of the following:

ISO Bank Identifier Code of the bank

Branch of the Receiver

Name and address of the Receiver

Other identification codes (for example, account number)

2-42

2.7.3.2 Parties

Ordering Institution

The Ordering Institution is the financial Institution, which is acting on behalf of itself, or a customer, to initiate the transaction. This field corresponds to 52a of SWIFT. In this field, you can enter one of the following:

The ISO Bank Identifier Code of the Ordering Institution

The branch or city of the Ordering Institution

The Name and address of the Bank

Account Number of the Ordering Institution

Country

Specify the country of the ordering institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Ordering Customer

The Ordering Customer refers to the customer ordering the transfer. Here, you can enter the name and address or the account number of the Customer, ordering the transaction. This field corresponds to field 50 of SWIFT. You will be allowed to enter details in this field only if you have initiated a customer transfer (MT 103 and MT 102). In case of an MT 910, a credit confirmation message, the first line should contain number ‘1’ in option F of field 50.

Country

Specify the country of the ordering customer. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Beneficiary Institution

Here, you can enter details of the institution in favor of which the payment is made. It is in reality the bank, which services the account of the Ultimate Beneficiary. This is applicable only in the case of bank transfers and not for customer transfers. This field corresponds to field 58a of

SWIFT

2-43

You will be allowed to make entries into this field only for Bank Transfers (when the remitter and beneficiary of the transfer are financial institutions

–MT 202). Here you can enter either:

The ISO Bank Identifier Code of the Beneficiary Institution

The Name and Address of the Beneficiary Institution

Account Number of the Beneficiary Institution

Country

Specify the country of the beneficiary institution. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Ultimate Beneficiary

The Ultimate Beneficiary refers to the Customer to whom the amount of the component is to be paid. This field refers to field 59 (is this now 59A) of SWIFT. You can make entries into this field only for a customer transfer (MT 103 or MT 100). This would not be applicable for Bank

Transfers, only for Customer Transfers. The system defaults the external account number in

Ultimate Beneficiary 1. If the country code is Spain, then the system applies CCC validation on the beneficiary account. If the country code is not Spanish, then the system applies IBAN validation.

You can also select an ultimate beneficiary account from the option list provided. Upon selection of the account, the Account with Institution of the selected ultimate beneficiary will appear by default in the AWI field in the Parties 1 tab. If no selection is made for AWI in the Parties tab 1 screen, then all accounts of ultimate beneficiaries existing in the system will be appear for selection.

Country

Specify the country of the ultimate beneficiary. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

Note the following:

The country information is captured to enable Mantas to analyse the transactions for possible money laundering activities.

For more details on Mantas, refer 'Mantas' interface document.

When the SWIFT message is capture d in the ‘Settlement Message Details – Parties’ screen, the system will display the parties involved in the transaction based on the values that come in the fields 52, 54, 55, 56, 57 58 etc. However, you can change the parties by choosing the appropriate value from the respective option lists. In case of the messages MT 103, MT202 and MT210, the option lists will display only those BICs for which the option ‘BEI Indicator’ is unchecked in the ‘BIC Code Maintenance’ screen.

However you can manually enter a B

IC for which the option ‘BEI Indicator’ is checked.

During message generation, the system will replace the BIC with the corresponding name and address of the party.

The number of banks/intermediaries involved in the transfer would, in practice depend on the:

Relationships and arrangements between the sending and receiving banks

Customer instructions

Location of parties

The banking regulations of a country

2-44

During the life-cycle of a contract you will be allowed to amend the details of a Settlement

Instruction only for those components which are yet to be settled.

2.7.3.3 Cover Parties

For local currency transactions for which the payment instructions are to be generated through the Payments module, you can specify the following settlement details:

Whether the payment is to be effected through messaging or via the local clearing network

Whether a cover is required for the payment

Whether the cover must be available through messaging or through the local clearing network

Beneficiary Institution for Cover

This field corresponds to field 58a of S.W.I.F.T. Enter details of the institution in favor of which the payment is made. It is in reality the bank, which services the account of the ultimate beneficiary.

You will be allowed to make entries into this field only for Bank transfers (MT 200 or MT 202). In this field you can enter either the:

The ISO Bank Identifier Code of the Beneficiary Institution

The Name and Address of the Beneficiary Institution

Country

Specify the country of the beneficiary institution for cover. This adjoining option list displays all valid country codes maintained in the system. You can choose the appropriate one.

The country information is captured to enable Mantas to analyse the transactions for possible money laundering activities.

For more details on Mantas, refer 'Mantas' interface document.

If you have already maintained this information in the Settlement Instructions Maintenance screen, then it will be picked up and reflected here.

You can specify these details in the Settlements Message Details screen. In the Message Details tab, you can indicate the payment mode, and the cover details.

2-45

If you indicate payment through the local clearing network, or cover through the local clearing network, you must indicate the external counterparty details in the Local Clearing tab in the

Settlement Message Details screen.

2.7.3.4 Other Details

Select the Counterparty Bank from the option list provided. All the Counterparty Accounts pertaining to this Bank will appear for selection. On selecting the Counterparty Account, the system will default the Counterparty Name as maintained for that account. If at the time of selecting Counterparty Account, Counterparty Bank is Null, then the Counterparty Bank will also appear by default.

For processing direct debits you will also need to capture the Agreement ID of the counterparty in order to facilitate a cross-referencing between the Payment and the Direct Debit instruction when a reversal of payment is carried out due to rejection of the outbound DD.

The Post Accounting option is defaulted from the Settlements to Payment Product and UDF

Mapping screen. If enabled this indicates that accounting entries maintained for the PC product should be posted for the PC contract initiated for Clearing.

Clearing Network

During Contract Input, Clearing Network in settlement screen will be d efaulted with ‘Clearing

Network’ maintained in local clearing section in settlement instruction.

Payment Bank

The system displays the payment bank.

Payable Branch

The system displays the payable branch.

Waive Charges On instrument Issue

Check this box to waive-off any instrument charges maintained at ARC maintenance.

2-46

2.7.4 Default MT 103 details

In the Settlement Instructions screen you would have maintained the default values for fields in

MT 103 messages that are generated in respect of contracts involving an entity, module, currency and branch combination.

When a contract is entered for the customer in any module, the values that you maintain here will be defaulted for MT 103 generation in respect of the contract, and you can view them in the

Settlement sub-screen of the contract main screen.

2.7.4.1 Clearing Details

You have the option of changing any or all of the default values for fields in MT 103 messages while processing a contract:

Bank Operation Code

You can indicate the bank operation code that will be inserted in Field 23B of the MT 103 message. The options available are SPRI, SSTD, SPAY and CRED.

Transaction Code

This is the code for the transaction type. This field corresponds to field 26T of the MT103 message.

Instruction Code

You can indicate the Instruction code that will be inserted in Field 23E of the MT103 message.

You can specify a maximum of six instructions codes here. However, you cannot repeat any code that has already been specified. The options available are:

CHBQ

TELE

PHON

PHOI

2-47

REPA

INTC

TELI

SDVA

PHOB

TELB

HOLD

CORT

Instruction Code Description

You can specify the additional information, if any, which would be inserted to qualify multiple

Instruction Codes in Field 23E of the MT103 message. The instruction code description can only be maintained for the following instruction codes

PHON

PHOB

PHOI

TELE

TELB

TELI

HOLD

REPA

For instance, if the Instruction Code is REPA and the description is

‘Repayment’ then the text

‘REPA/Repayment’ is inserted in Field 23E.

Regulatory Reporting Details

You can select the Regulatory Reporting Details from the option list displaying the following values:

/BENEFRES/

/ORDERRES/

The chosen value will be inserted in Field 77B of the MT103 message.

Time Indicators

Time Indication, specifies one or several time indication(s) related to the processing of the payment instruction. Select the time indication code from the following values available in the option list:

/CLSTIME/ - Time by which funding payment must be credited, with confirmation, to the

CLS Bank's account at the central bank, expressed in CET.

/RNCTIME/ - Time at which a TARGET payment has been credited at the receiving central bank, expressed in CET

/SNDTIME/ - Time at which a TARGET payment has been debited at the sending central bank, expressed in CET

2-48

2.7.5 Amending Settlement Details

While amending a contract, you can modify the settlement information on the following tabs:

Message Details

Parties

Cover Parties

Clearing Details

Save the contract once you have made the required changes. The system validates the modified information as in case of a new settlements operation.

2.8

SWIFT messages handled by Oracle FLEXCUBE

The following table gives the SWIFT message types that will be generated for the various transfers that can be initiated through Oracle FLEXCUBE.

Type of Transfer

Customer Transfer

Message Type

MT 103/ MT 100

Customer Transfer with Cover MT 103/ 100 and MT 202

Bank Transfer MT 202

Bank Transfer with Cover MT 205

Bank Transfer for Own Account MT 200

Notice to Receive

Direct Debits

ACK Status

MT 210

MT 104

MT 012

NAK Status MT 019

2.8.1 Payment Message - MT 100 (103)

Sending a Fax copy of an MT 103

For outgoing transfers, you have the option to generate a fax copy of a Payment Message (MT

103) that is sent when the transfer is initiated (INIT). A fax copy of an MT 103 can be triggered for generation:

Automatically, when the MT 103 is generated

When a customer requests one

The format and content of the fax will be similar to the corresponding SWIFT Payment Message.

A fax copy of an MT 103 can be sent to the counterparty of a transfer only if the Payment

Message (PAYMENT_MESSAGE) was triggered at the transfer initiation event (INIT).

2-49

Generated with a Payment Message

While indicating the messages that should be generated at the event (INIT), you should also associate the pre-shipped advice type FAX_PMT_MSG to the event.

When the FT is authorized, the MT 103 is generated from the Outgoing Message Browser and the Fax copy is triggered for generation.

Generation of a unique reference number for Field 20

If the

‘SWIFT_SILVER’ parameter has been set to ‘YES’ for your bank, during the funds transfer a unique reference number will be generated in field 20.

The unique reference number is a combination of the first 7 characters of the contract reference number, a single digit unique number and the last 8 characters of the contract reference number.

The single digit unique number is obtained as follows:

For all credit type transfers (MT910, MT200, MT103, MT103P, MT202 and cover message) it would be ‘2’. If the cover message is also sent along with the payment messages then it would be

‘3’. For debit type transfers (MT210 and MT900) it would be ‘1’.

Due to this setup, during the Nostro reconciliation process, the internal reference number of transaction related to funds transfer module would be modified before comparison with the external reference number.

This message type is sent by or on behalf of the financial institution of the ordering customer directly or through a correspondent(s), to the financial institution of the beneficiary customer.

Given below is a list of fields present in an MT 103 message type.

Message

Type

Field Tag Description

MT103 20 Transaction Reference Number. If the

‘SWIFT_SILVER’ parameter has been set to

‘YES’ for your bank, a unique reference number will be generated instead of the transaction reference number.

Value Date, Currency Code and Amount 32A

50 (Ordering

Customer)

52a (Ordering

This information you have maintained for the

Ordering Customer field in the Other

Messages tab of the Settlements screen is defaulted here. For outgoing MT103, the first line should have number 1 present in option

F.

If the ordering customer specified is a valid

BIC then the system will update field 50a with this BIC. If the BIC is not a valid code, the system will display the name and address of the customer instead (as per option K).

This field gets populated depending on your

2-50

Message

Type

Field Tag

Institution)

Description

53a (

Correspondent)

53B

54a (

Correspondent)

55 (Third

Reimbursement bank)

56a

Sender’s

Receiver’s

(Intermediary)

57a (Account

With Institution)

59 (Beneficiary

Customer)

70 (Details of entry in the Ordering institution field. If the transfer has originated from a different bank, this field should contain the name of the

Originating Bank. If you do not need this field, clear the data from this field.

The information that is captured for the

Receiver of Cover field in the Settlement

Instructions screen is defaulted if a cover is sent. Else the BIC of the Nostro account is defaulted.

This field gets populated only if there are multiple account relationships between the sender and the receiver correspondents.

This field gets populated based on your entry in the Receiver Correspondent field in the

Settlement Instructions screen. The information available in this field can be deleted if you do not need it.

This field Specifies the Receiver's branch, when the funds are made available to this branch through a financial institution other than that indicated in field 53a.

This information maintained for the

Intermediary field is defaulted here. You can change it.

The information maintained for the Account

With Institution field is displayed here. You have the option of changing it. If the value for field 72 does not contain the string

‘/RCB/’ and field 55 is not null, then the value in field

55 will be displayed here. If field 55 is null, then the value in field 54 will be displayed here.

The information maintained in the Ultimate

Beneficiary field is defaulted here. You have the option of deleting this information.

Here you need to link this tag content to the customer account and sender to the counter party BIC.

If the ultimate beneficiary of the transaction is a valid BIC, then this field will display the BIC.

In case the beneficiary BIC is invalid, then the field value will be null.

The Details of Payment captured in the

2-51

Message

Type

Field Tag

Payment)

71A

71F

71G

72 (Sender to

Receiver

Information)

Description

Settlements screen will be defaulted here.

Information is defaulted from the Charge

Bearer field in the FT Contract screen.

Sender’s Charges.

Receiver’s Charges.

If you have captured the ERI Currency and

Amount in the Settlements screen the OCMT is populated along with the data in the Sender

to Receiver information field in the

Settlements screen.

Some of the fields like field 20 and 32A are generic in nature. The details pertaining to the other fields are defaulted from your maintenance in the Settlement Instructions screen.

Field 32A will display the credit amount and currency, while field 33B will display the debit amount and currency in case of cross-currency payments. In case of intra-European payments where

‘EUR’ is the only currency involved, field 33B will display the transaction amount. In such cases, input to field 33B will be mandatory.

The s ender’s charge currency of previous banks in the payment chain will be appended in field

71F of an outgoing MT103. During the STP of an incoming MT103, the fields 32A and 33B will not be compared to fields 71F and 71G. While processing an incoming payment message where the value for field 71A is

‘OUR’ and 71G is also present, the system will compute the transfer amount by subtracting the receiver’s charges from the credit amount. Receiver’s charges will not be displayed in an outgoing MT 103.

2.8.2 MT 100 (Customer Transfer)

The MT100, which is a customer transfer message, consists of 12 fields each having its own identity and field number.

This message type is sent by or on behalf of the financial institution of the ordering customer directly or through a correspondent(s), to the financial institution of the beneficiary customer.

Given below is a list of fields present in an MT 100 message type.

Message Type Field Tag

MT100 20

32A

50 (Ordering

Description

Transaction Reference Number. If the

‘SWIFT_SILVER’ parameter has been set to

‘YES’ for your bank, a unique reference number will be generated instead of the transaction reference number.

Value Date, Currency Code and Amount

This information you have maintained for the

2-52

Message Type Field Tag

Customer)

52a (Ordering

Institution)

53a (

Sender’s

Correspondent)

54a (

Receiver’s

Correspondent)

56a

(Intermediary)

57a (Account

With Institution)

59 (Beneficiary

Customer)

70 (Details of

Payment)

71A

72 (Sender to

Receiver

Information)

Description

Ordering Customer field in the Other

Messages tab of the Settlements screen is defaulted here.

This field gets populated depending on your entry in the Ordering institution field. If the transfer has originated from a different bank, this field should contain the name of the

Originating Bank. If you do not need this field, clear the data from this field.

The information that is captured for the

Receiver of Cover field in the Settlement

Instructions screen is defaulted if a cover is sent. Else the BIC of the Nostro account is defaulted.

This field gets populated based on your entry in the Receiver Correspondent field in the

Settlement Instructions screen. The information available in this field can be deleted if you do not need it.

This information maintained for the

Intermediary field is defaulted here. You can change it.

The information maintained for the Account

With Institution field is displayed here. You have the option of changing it.

The information maintained in the Ultimate

Beneficiary field is defaulted here. You have the option of deleting this information.

Here you need to link this tag content to the customer account and sender to the counter party BIC.

The Details of Payment captured in the

Settlements screen will be defaulted here.

Information is defaulted from the Charge

Bearer field in the FT Contract screen.

If you have captured the ERI Currency and

Amount in the Settlements screen the OCMT is populated along with the data in the Sender

to Receiver information field in the

Settlements screen.

Some of the fields like field 20 and 32A are generic in nature. The details pertaining to the other fields are defaulted from your maintenance in the Settlement Instructions screen.

2-53

2.8.3 MT 102 (Consolidated Customer Transfer with Cover)

During Close operation of a consolidation if the PAYMENT_MESSAGE is linked as an advice to the INIT event for the PC product, then the following two message types are created -

CONS_CUST_TRANS

– This would represent consolidated customer transfer i.e. MT102

CONS_COVER

– This would represent consolidated cover message generated for MT102

The MT102 would consists of three sequences -

Sequence A: This contains General Information and is a single occurrence sequence and contains information which applies to all individual transactions described in sequence

B.

Sequence B: This contains Transaction Details in a repetitive sequence. Each occurrence is used to provide details of one individual transaction

Sequence C: This contains the Settlement Details and is a single occurrence sequence and contains information about the settlement

Mandatory Sequence A General Information

20

23

M File Reference Accounting Entry Ref.

M Bank Operation

Code

Bank Operation Code

50a O Ordering

Customer or K)

– (A

This field would be filled up only if the Ordering

Customer for all the underlying FT Contracts is same.

For outgoing MT102, the first line should have number

1 present in option F.

This field would be filled up only if the Ordering

Institution for all the underlying FT Contracts is same.

52a O Ordering

Institution

– (A or B or C)

26T

77B

71A

36

O Transaction

Type Code

O Regulatory

Reporting

O Details of

Charges

This field would be filled up only if the Transaction Type codes for all the underlying FT Contracts are the same.

This field would be filled up only if the Regulatory

Reporting for all the underlying FT Contracts are the same.

This field would be based on ‘Charge Whom’ and will be filled up only if ‘Charge Whom’ is same for all the underlying FT Contracts.

O Exchange Rate This field would be filled up only if the Cr. Currency,

Settlement Currency and Exchange Rate for all the underlying FT Contracts are the same and Cr.

Currency <> Settlement Currency.

Mandatory Repetitive Sequence B Transaction Details

21 M Transaction

Reference

FT Contract Ref No

2-54

Mandatory Sequence A General Information

32B M Transaction

Amount

OUR or SHA- Credit Currency and Credit Amount

BEN - Credit Currency and (Credit Amount

– Sender’s

Charges)

50a O Ordering

Customer (A or

K)

This field would be filled up only if the Ordering

Customer for the underlying FT Contracts differs.

52a O Ordering

Institution (A or

B or C)

This field would be filled up only if the Ordering

Institution for the underlying FT Contracts differs.

57a O Acct With

Institution (A or

C)

Account With Institution details of FT Contract.

59a M Beneficiary

Customer (A or

No letter)

Beneficiary Customer details of FT Contract.

70 O Remittance

Information

Payment Details of FT Contract.

26T O Transaction

Type Code

77B O Regulatory

Reporting

This field would be filled up only if the Transaction

Type codes for the underlying FT Contracts differ.

This field would be filled up only if the Regulatory

Reporting for the underlying FT Contracts differs.

33B O Currency/Instru cted Amount

71A O Details of

Charges

This field will be populated only if the Credit Amount

<> 32B

This field would be based on ‘Charge Whom’ and will b e filled up only if ‘Charge Whom’ for the underlying

FT Contracts differs.

Sender’s Charges

71F O

Sender’s

Charges

71G O

Receiver’s

Charges

Receiver’s Charges

36 O Exchange Rate This field would be filled up in case the Currency

Codes in Field 32B and 33B are different.

Mandatory Sequence C Settlement Details

32A M Value Date,

Currency

Code, Amount

Sum of all (Amounts in 32B + Sum of Receiver’s

Charges if Charge Whom = ‘OUR’ else this is equal to the Amount in 32B)

19 O Sum of Sum of all amounts in 32B

2-55

Mandatory Sequence A General Information

Amounts

Sum of Receiver’s Charges

71G O Sum of

Receiver’s

Charges

53a O

Sender’s

Corresponden t

54a O

Receiver’s

Corresponden t

Sender’s Correspondent.

Receiver’s Correspondent

72 O Sender to

Receiver

Information

Payment Details of FT Contract.

2.8.3.1 End of Transaction Input for MT102`

The End of Transaction Input (EOTI) process will display an error message if there are some pending consolidated transactions in MT102 consolidation queue.

2.8.3.2 Processing Incoming MT102

The following will be the sequence of processing incoming swift message MT 102:

MT102 upload process would decompose the message to create multiple MT103’s with

Consolidation status Yes

Decomposition process validates whether any transaction is creating an outgoing message i.e. whether the bank is acting as an agent or not and if such a case exists, then entire message (MT102) would be sent to repair queue. Therefore, only incoming MT102 meant for the current branch would be supported. Conditions to be met for Incoming message :

 Tag 57A is Same as Receiver of the message

 Tag 57A is not present

If above condition is not satisfied then message would be rejected.

The decomposition process would create following entries

 Dr. Sender’s NOSTRO (Consolidated Amount)

 Cr. MT102 Incoming Suspense GL maintained at Branch level (Consolidated

Amount)

The above entry’s accounting reference number would be stored in ‘Consolidated Acc.

Ref

’ Number Field of each contract

STP rule would be enhanced to provide information of consolidation flag. This function would help to route incoming MT103 (generated due to MT102) to the

‘Multi Credit

Transfer

’ Product.

All the MT103 generated would be routed to the same

‘Multi Credit Transfer’ product using

Consolidation flag at message level

2-56

The incoming process of MT103 would populate

‘Multi. Credit Reference’ Number at contract level with

‘Consolidation reference’ (tag 20 of MT102) number present at message level.

Incoming upload Process of MT103 which are linked to the

‘Multi. Credit Transfer’ would pass following entries at each transaction level.

Dr. MT102 Clearing Suspense GL

Cr. DAO/ Beneficiary

A field called

‘Multi Credit Ref No’ will be available in the Incoming Browser. This would be populated for all the MT103 generated due to an incoming MT102 and would be populated with the value of tag 20 in Sequence A of the MT102.

2.8.4 MT 200 (Financial Institution Transfer for its Own Account)

In Oracle FLEXCUBE, you need to capture specific information against each field number for the

Amount Tag

– TRF_AMT.

Message Type Field Tag

MT200 20

21

32A

53B (Sender’s

Correspondent)

56a

(Intermediary)

57a (Account

With Institution)

72 (Sender to

Receiver

Information)

Description

Transaction Reference Number. This message type should not start or end with a ‘/’ or ‘//’. This displays the Contract Reference number for most contracts.

For an LC, BC and LD message, the user reference number is displayed. For an FT message, the source reference number is displayed. If the

‘SWIFT_SILVER’ parameter has been set to ‘YES’ for your bank, a unique reference number will be generated instead of the transaction reference number.

Related Reference Number. This is the contract reference number in most cases. However, for a

Money Market confirmation message, the common reference number of the contract is displayed in this field. For an LC message, the user reference number is displayed. For an FT message, the source reference number is displayed.

Value Date, Currency Code, Amount

Your entry for Our Correspondent in the Settlement

Instructions screen is defaulted here.

Your entry for the Intermediary field in the

Settlement Instructions screen is defaulted here.

Your entry against the Account With Institution field in the Settlement Instructions screen id defaulted here.

2-57

2.8.5 MT 202 (General Financial Institution Transfer)

Notification of this type is sent by the Bank-Payer or on its behalf, directly or through correspondent

(correspondents), to the financial institution serving the account of the Bank-Beneficiary.

All information pertaining to this message should be captured against the amount tag TRF_AMT.

Message Type Field Tag Description

MT 202 20

21

32A

Transaction Reference Number. This message type should not start or end with a ‘/’ or ‘//’. This displays the Contract

Reference number for most contracts. For an LC, BC and

LD message, the user reference number is displayed. For an FT message, the source reference number is displayed.

If the ‘SWIFT_SILVER’ parameter has been set to ‘YES’ for your bank, a unique reference number will be generated instead of the transaction reference number.

Related Reference Number. This is the contract reference number in most cases. However, for a Money Market confirmation message, the common reference number of the contract is displayed in this field. For an LC message, the user reference number is displayed. For an FT message, the source reference number is displayed.

Value Date, Currency Code, Amount

52a

(Ordering

Institution)

57a

(Account

With

Institution)

Your entry for Ordering Institution in the Settlement

Message Details screen is defaulted here. If the transfer is originating from a different bank you will need to capture the relevant data in this field. You will also need to capture information if the ordering institution is different from the

Sending institution.

This is field 54 of the corresponding MT103.

During STP, if this field is null in the incoming message, the system will not send an outgoing MT202. It will only book an incoming payment.

58a

(Beneficiary

Institution)

The details of the receiver in the corresponding MT100 are defaulted here.

You can capture the BIC code or the CIF Number assigned to the bank in this field.

In MT103, MT103P and MT202 if the value in field 52 (Ordering Institution) is the same as th e sender’s correspondent, then field 52 will be suppressed during message generation.

2-58

2.8.6 MT 205 (Financial Institution Transfer Execution)

This message is sent by the Receiver of a category 2 transfer message, i.e., MT 200, 201, 202,

203 or 205, directly or through correspondent(s), to another financial institution located in the same country as the Sender. It is used to further transmit a funds transfer instruction domestically.

Message

Type

Field

Tag

Description

MT 205 20 Transaction Reference Number. If th e ‘SWIFT_SILVER’ parameter has been set to ‘YES’ for your bank, a unique reference number will be generated instead of the transaction reference number.

21 Related Reference

32 A Value Date, Currency Code, Amount

52 a Ordering Institution

53 a Send er’s Correspondent

56 a Intermediary

57 a Account With Institution

58 a

Beneficiary Institution

72

Sender to Receiver Information

2.8.7 MT 202COV / 205COV

For customer credit transfers, you can send the outgoing payment messages in MT 202 COV or

MT 205 COV formats, if the receiver currency supports these formats.

Status Tag Field Name Content/Options

Mandatory Sequence A General Information

M 20 Transaction Reference Number

21 Related Reference M

----->

13C Time Indication O

-----|

M

O

32A

52a

Value Date, Currency Code, Amount

Ordering Institution

16x

16x

/8c/4!n1!x4!n

6!n3!a15d

A or D

2-59

Status Tag Field Name

O 53a Sender's Correspondent

O

O

54a

56a

Receiver's Correspondent

Intermediary

O

M

57a

58a

Account With Institution

Beneficiary Institution

O 72 Sender to Receiver Information

End of Sequence A General Information

Content/Options

A, B, or D

A, B, or D

A or D

A, B, or D

A or D

6*35x

O

M

O

O

Mandatory Sequence B underlying customer credit transfer details

M 50a Ordering Customer A, F, or K

O

O

52a

56a

Ordering Institution

Intermediary Institution

A or D

A, C, or D

57a

59a

70

72

Account With Institution

Beneficiary Customer

Remittance Information

Sender to Receiver Information

A, B, C, or D

No letter option or A

4*35x

6*35x

O 33B Currency/Instructed Amount 3!a15d

End of Sequence B underlying customer credit transfer details

M = Mandatory, O = Optional

2.8.7.1 Processing Outgoing MT202 COV / MT205 COV Messages

For non-STP contracts, booked from any module, outgoing messages are generated in the new

COV format depending on the transfer type, the value specified for the ‘Cover Required’ option, the country codes of the sender and receiver provided that the receiver currency supports the new formats. The following message types are used to handle the cover messages in the new format:

CUST_COVER

CUST_COVERL

CUST_RTGS_COV

The cover message format to be used during message generation is derived as follows:

2-60

If transfer type is

‘CustomerTransfer’, ‘Cover required’ is true and country codes of sender and receiver are same and the receiver currency allows new COV format, then the system uses following message format:

CUST_COVERL (MT205COV)

If transfer type is

‘CustomerTransfer’ , ‘Cover required’ is true and country codes of sender and receiver are same and if the receiver currency does not allow new COV format, then the system uses following message format:

COVERL (MT205 old cover format)

If transfer type is ‘CustomerTransfer’ , ‘Cover required’ is true and currency of sender and receiver are not same and if receiver currency allows new COV format, then the system uses following message format:

CUST_COVER (MT202COV)

If transfer type is ‘CustomerTransfer’ , ‘Cover required’ is true and currency of sender and receiver are not same and if receiver currency does not allow new COV format, then the system uses following message format:

COVER(MT202 old cover format)

If transfer type is

‘CustomerTransfer’ and settlement has ‘RTGS cover required’ enabled ad if the network level flag allows new COV format, then the system uses following message format:

CUST_RTGS_COV (new RTGS COV format, similar to 205COV format)

If transfer type is

‘CustomerTransfer’ and settlement has ‘RTGS cover required’ enabled ad if the network level flag does not allow new COV format, then the system uses following message format:

COVER_RTGS (old RTGS cover format)

2.8.7.2 Processing Incoming MT202 COV / MT205 COV Messages

FT products with the transfer type as ‘CustomerTransferCover’ will be used to handle the incoming SWIFT messages. The cover message format to be used during message generation is derived as follows:

If transfer type is

‘CustomerTransferCover’ and country codes of sender and receiver are same and if the receiver currency allows new COV format then the system uses following message format:

CUST_COVERL (MT205COV)

If transfer type is

‘CustomerTransferCover’ and country codes of sender and receiver are same and if the receiver currency does not allow new COV format then the system uses following message format:

COVERL (MT205 old cover format)

If transfer type is

‘CustomerTransferCover’ and currency of sender and receiver are not same and if the receiver currency allows new COV format then the system uses following message format:

CUST_COVER (MT202COV)

If transfer type is

‘CustomerTransferCover’ and currency of sender and receiver are not same and if the receiver currency does not allow new COV format then the system uses following message format:

COVER(MT202 old cover format)

If transfer type is

‘CustomerTransferCover’ and settlement has ‘RTGS cover required’ enabled and if the network level flag allows new COV format then the system uses following message format:

2-61

CUST_RTGS_COV (new COVER_RTGS format, similar to 205COV format)

If transfer type is

‘CustomerTransferCover’ and settlement has ‘RTGS cover required’ enabled and if the network level flag does not allow new COV format then the system uses following message format:

COVER_RTGS (old RTGS cover format)

2.8.8 MT 210 (Notice to Receive)

All information pertaining to this message should be captured against the amount tag TRF_AMT.

Message

Type

Field Tag Description

MT 210 20

21

Transaction Reference Number. This message type should not start or end with a ‘/’ or ‘//’. This displays the Contract Reference number for most contracts. For an LC, BC and LD message, the user reference number is displayed. For an FT message, the source reference number is displayed.

If the ‘SWIFT_SILVER’ parameter has been set to ‘YES’ for your bank, a unique reference number will be generated instead of the transaction reference number.

Related Reference Number. This is the contract reference number in most cases. However, for a Money Market confirmation message, the common reference number of the contract is displayed in this field. For an LC message, the user reference number is displayed. For an FT message, the source reference number is displayed.

25

30

21

32B

Account Identification

Value Date

Related Reference Number.

Currency Code, Amount

50

(Ordering

Customer)

The information captured in the Ordering Customer details field will be defaulted here only if the details are different from the

Ordering Institution.

For outgoing MT210, the first line should have number 1 present in option F.

52a

(Ordering

Institution)

This is the BIC of the Sending Bank. The information maintained in the Ordering Institution field of the Settlement Message Details screen is defaulted here.

If the BIC of the ordering institution and sending bank are the same, this field generation in the message is mandatory.

56a

(Intermedi ary)

The information captured in the Intermediary field of the

Settlement Message details screen is defaulted to this field. You have the option of deleting the information captured in this field.

2-62

2.8.9 MT 320 (Fixed Deposit Confirmation)

Message

Type

Field Tag Description

MT 320 20 Transaction reference Number

. If the ‘SWIFT_SILVER’ parameter has been set to ‘YES’ for your bank, a unique reference number will be generated instead of the transaction reference number.

30X

34E

37G

14D

30T

30V

30P

32B

21

22

30

31C

32a

33a

34a

37a

22A

22C

Related Reference Number

Code/Common Reference

Date Contract Agreed/Amended

Maturity Date of Deposit

Value Date of Deposit, Currency Code. Contract Amount.

Value Date for Change, Currency Code, Principal Amount to be Transferred.

Next interest Due Date, Currency Code, interest Amount

Interest Field

NEWT/AMND depending on whether the contract is being booked or amended.

Common Reference Number according to the SWIFT validation rules.

Booking date of the contract

Value Date of the contract

Maturity Date of the contract

Contract Currency and Contract Amount

Next interest date in case of schedules else Maturity Date.

Currency and Interest amount.

Interest Rate

Interest calculation basis in ICCF screen for interest.

15C LENDING The information associated with the amount tag PRINCIPAL is defaulted from the Settlement Instructions screen.

53A/53D Account holder of the settlement account

2-63

Message

Type

Field Tag Description

15D

56A/56D

57A/57D

58A/58D

BORROWI

NG

53A/53D

56A/56D

57A/57D

58A/58D

Details entered in the intermediary field in the settlement instruction screen.

Details entered in the Account With Institution field in the

Settlement Instruction screen.

Details entered in the Beneficiary Institution field in the

Settlement Instruction screen.

The information associated with the amount tag

PRINCIPAL_LIQD is defaulted from the Settlement

Instructions screen.

Account holder of the settlement account

Details entered in the intermediary field in the settlement instruction screen.

Details entered in the Account With Institution field in the

Settlement Instruction screen.

Details entered in the Beneficiary Institution field in the

Settlement Instruction screen.

LENDING The information associated with the amount tag

PRINCIPAL_LIQD is defaulted from the Settlement

Instructions screen.

53A/53D

The details entered in the Receiver’s Correspondent field are defaulted in this field.

56A/56D

57A/57D

58A/58D

Details entered in the Intermediary field in the Settlement

Instructions screen are defaulted in this field.

Details entered in the Account With Institution field in the

Settlement Instruction screen are defaulted here.

Details entered in the Beneficiary Institution field in the

Settlement Instruction screen are defaulted here.

BORROWI

NG

53A/53D

56A/56D

57A/57D

The information associated with the amount tag PRINCIPAL is defaulted from the Settlement Instructions screen.

Details entered in the Receiver’s Correspondent field in the

Settlement Instructions screen are defaulted here.

Details entered in the Intermediary field of the Settlement

Instructions screen are defaulted here.

Details entered in the Account With Institution field in the

Settlement Instruction screen are defaulted here.

2-64

Message

Type

Field Tag Description

58A/58D Details entered in the Beneficiary Institution field in the

Settlement Instruction screen.

2.8.10 MT 300 (Foreign Exchange Confirmation)

Message Type Field Tag

MT 300 15A

22A (Scope of

Operation)

22C (Common

Reference)

30T (Trade Date)

Description

New Sequence

NEWT/AMND depending on Contract booking or

Amendment.

Common Reference Number, according to the

SWIFT validation rules.

30V (Value Date)

36

Booking date for the Contract Booking (NEWT) event. Event date for all other events.

Bought Value Date.

Exchange Rate

32B (Bought

Currency, Amount)

The information pertaining to these fields is picked up from the settlement detailed maintained for the

Amount Tag

– SETBOTAMT.

53a (Delivery Agent) The details entered in the Receiver's

Correspondent field in the settlement Instructions screen are defaulted here.

56a (intermediary) The details entered in the Intermediary field in the

Settlement Instructions screen.

57a (Receiving

Agent)

33B (Sold Currency and Sold Amount)

The information pertaining to these fields is picked up from the settlement detailed maintained for the

Amount Tag

– SETSOLDAMT.

53 (Delivery Agent) The delivery agent is the account holder of the settlement account for SETSOLDAMT.

56

Details entered in the Account With Institution field in the Settlement Instructions screen.

If the data is not available then the field will be populated with UNKNOWN according to the

SWIFT requirements.

57a (Receiving

The details entered in the intermediary field in the settlement instructions screen.

The details entered in the Account With Institution field in the Settlement Instructions screen. If the

2-65

Message Type Field Tag

Agent)

58

Description

data is not available then the field will be populated with UNKNOWN according to the

SWIFT requirements

The details entered in the Beneficiary Institution field in Settlement Instructions for the Amount Tag

SETBOTAMT

2.8.11 MT 400 (Advice of Payment)

The receiver of the MT400 is the Remitting bank. The details are captured in the Parties section of the Settlements screen.

If the Remitting bank is not a customer of your bank, you can use the CIF ID assigned to the walk-in customer. You will also have to capture the SWIFT address of the remitting bank.

If the Remitting bank is not a customer of your bank and you have used the CIF ID assigned to the walk-in customer you will have to change the media to SWIFT in the Advices/FFT tab for generating the Collection Payment advice (COLL_PAY_ADV).

If you choose not to send an MT 400, the message can be suppressed in the Advices/FFT screen. A MT100 and MT202 (Cover) can be send instead by choosing the Cover Required option in the Settlements Instruction screen.

Message Type Field Tag

MT400

Description

53A/D

(Sender’s/

Receiver’s

Correspondent)

The receiver of MT202. The information captured in the Receiver field of the Settlement Instruction screen for the Amount Tag BILL_LIQ_AMT is defaulted here.

This field is not populated if the receiver of MT400 is same as Our Correspondent.

54A/D and

57A/D

If you would like both field 54 and 57 to appear in the generated message you will have to capture the relevant data in the Receiver Correspondent and

Account With Institution fields against the Amount

Tag BILL_LIQ_AMT.

If only field 54 is required in the SWIFT message, you will have to capture data in the Account With

Institution field and leave the Receiver

Correspondent field blank.

Consequently, the accompanying MT202 shall contain fields 54 and 57 depending on the availability of data in Receiver Correspondent and

Account With Institution fields respectively.

The information pertaining to fields 20 (Sending Bank’s TRN), 21 (Related Reference), 32a

(Amount Collected), 33A (Proceeds Remitted), is picked up from the contract details screen.

2-66

2.8.12 Payment Message Generation for MT300/320

In Oracle FLEXCUBE, a new parameter CSTB_PARAM is introduced. The account number indicated in the party identification fields 56a and 57a of the MT 300/320/330 are serviced and not owned by the party indicated in the same field. If the value of this parameter is ‘Y’ and if the account lines of fields 56 & 57 do not have sort codes, then:

The account number in field 58 is populated in the account line of field 57

The account number in field 57 is populated in the account line of field 56

2.8.12.1 Processing for Incoming MT300/320

Based on the value of the parameter CSTB_PARAM, the incoming message processing will fetch the account number for pay and receive

. If the parameter value is ‘Y’, the account number is fetched from field 56 instead of field 57. Otherwise, the account number of pay and receive will be fetched from field 57.

2.8.13 MT 756 (Advice of Reimbursement or Payment)

The receiver of the MT756 is the Remitting/ Negotiating bank. The details are captured in the

Parties screen.

If the Remitting bank is not a customer of your bank, you can use the CIF ID assigned to the walk-in customer. You will also have to capture the SWIFT address of the remitting bank.

If the Remitting bank is not a customer of your bank and you have used the CIF ID assigned to the walk-in customer you will have to change the media to SWIFT in the Advices/FFT tab for generating the Reimbursement Payment advice (REIM_PAY_ADV).

If you choose not to send an MT 756, the message can be suppressed in the Advices / FFT screen. An MT100 and MT202 (Cover) can be sent instead by choosing the Cover Required option in the Settlements Instruction screen.

Message Type Field Tag

MT 756

Description

53A/D

(Sender’s

Correspondent)

The receiver of MT202. This is the data input in the receiver field in the Settlement Instruction screen for the Amount Tag BILL_LIQ_AMT. This field is not populated if the receiver of the MT756 is the same as

Our Correspondent.

54A/D

(Receiver’s

Correspondent)

Your entry for this field should be provided in the

Account With Institution field in the Settlement

Instructions screen for the Amount Tag

BILL_LIQ_AMT. The data in this field will appear as

57A in the accompanying MT202.

MT 910

72

50

52a

56a

Sender to Receiver Information.

This is mandatory and needs to be validated.

This is mandatory and needs to be validated.

This field is populated with the institution from which sender received the funds. This is applicable only if

2-67

Message Type Field Tag Description

the institution is different from the ordering institution.

The information pertaining to fields 20 (Sending Bank’s TRN), 21 (Presenting Bank’s

Reference), 32B (Total Amount Claimed), 33A (Amount Reimbursed or Paid), is picked up from the contract details screen.

2.8.14 MT 012 (ACK Status Acknowledgement)

In PC contract online is provided with ACK Status having values -

P - Pending

A

– ACK

N - NAK

After message dispatch, the ACK status is updated to

‘Pending’. Subsequently during processing of MT012 status changed to

‘ACK’ ad ‘ACK Status’ is updated in Transaction online and

Transaction Summary screen also.

Incoming Swift Upload process support MT012 would contain either

Reference number PC Contract

DCN of the outgoing message that was generated

Reference number present in field 108 of MT012 is searched first in PC Contract and upon receiving MT012, the ACK_STATUS of the record is marked to ACK. In case of the record not getting updated in the Contract Master, the message table is queried for DCN in field 108 to obtain the reference no. of the corresponding PC Contract and the ACK_STATUS is marked as

ACK.

2.8.15 MT 019 (NAK Status Acknowledgement)

After message dispatch, the ACK status is NAK during processing of MT019 changing the status to

‘NAK’. Subsequently ‘NAK Status’ is updated in Transaction online and Transaction Summary screen also.

Incoming Swift Upload process support MT019 would contain either

Reference number PC Contract

DCN of the outgoing message that was generated

Reference number present in the field of MT019 is searched first in PC Contract and upon receiving MT019; the NAK_STATUS of the record is marked to NAK. In case of the record not getting updated in the Contract Master, the message table is queried for DCN in the field to obtain the reference no. of the corresponding PC Contract and the NAK_STATUS is marked as NAK.

Given below are some examples of the SWIFT messages discussed above.

Example I

– Customer Transfer

Ms. Tanya Agnihotri, a customer of your bank (Bank Austria Vienna) instructs you to transfer Dutch Guilders

100,000 to the account of Ms. Tina Shenoy with Citibank, Mumbai, for her birthday.

Message Details Format Explanation

2-68

Message Details

Sender

Format Explanation

BKAUATWWA The BIC Code assigned to

Bank Austria, Vienna

103 Message Type

Receiver CITIBKINMU0 The BIC Code assigned to

Citibank, Mumbai.

Message Text

Sender Reference

Sender’s Correspondent

Ultimate Beneficiary

Details of Payment

:20:494931/DE

V

:23b:CRED Bank Operation Code

Value date/ Currency/ Interbank settled amount

:

32A:020426NL

G100000,

Field 32 A of SWIFT

Ordering Customer :50K:Tanya

Agnihotri

Field 50 K of SWIFT

:53B:CITIBKUS

NY1

Field 53 B of SWIFT.

The correspondent bank is

Citibank, New York

Field 59 of SWIFT :59:Tina

Shenoy

:70: Birthday

Gift

Field 70 of SWIFT

Example II - Payment Order

— MT 202

Message Details

Sender

Message Type

Receiver

Message Text

Transaction Reference

Number

Related Reference

Value date/ Currency code/

Amount

Format

BKAUATWWA

202

CITIBKUSNYX

:20:203998988

:21:494931/DEV

:32A:020426NLG100000,

Explanation

Field 20 of MT 103

2-69

Message Details

Beneficiary Institution

Format

:58:CITIBKINMU0

Explanation

Field 57a of SWIFT

The bank is Citibank

Mumbai.

End of message text/trailer

Field In Oracle

FLEXCUBE

Example III - MT 200

You, (Bank Austria, Vienna) order Citibank, NY to transfer NLG 1 Million from your Nostro account with them, to your Nostro account with HDFC bank, Mumbai.

An Intermediary can be involved in this transfer, if Citibank, NY, requests Citibank, Mumbai, to transfer the funds to HDFC, Mumbai. In this case Citibank, Mumbai will be the Intermediary.

Example IV - MT 202

In the example for MT 200, if you involve an Intermediary (field 56a of SWIFT ) then a cover MT 202 will be sent to Citibank, Mumbai.

Example V - Notice to Receive (MT 210)

As a result of a Foreign Exchange deal with HDFC, Mumbai, you at Bank Austria, Vienna, are expecting to receive 1 Million USD to be credited to your account with Citibank, NY.

Notice To Receive: MT210

Corresponding Field in

SWIFT

Entry

Ordering Institution

Sender

Intermediary

Details of Payment

Field 52a of SWIFT

Field 56a of SWIFT

Field 70 of SWIFT

HDFC, Mumbai

Bank Austria, Vienna

Citibank, Mumbai

A message that you want to send.

The Notice to Receive MT 210 will be sent from Bank Austria, Vienna, to Citibank, New York.

Example VI - Debit Advice (MT 900)

An MT 900 is a debit advice. It is sent by the Account Servicing institution to notify an account owner of an entry that has been debited to its account.

Bank Austria, Vienna asks Citibank, NY, to pay Citibank, Mumbai by debiting Bank Austria’s account with

Citibank, New York.

An MT 900 is sent by Citibank, NY, after it pays Citibank, Mumbai and debits Bank Austria’s account with it.

2.8.16 MT110 (Advise of Cheque)

This message type will be generated in case instrument to be issued in FCY. The receiver of the

MT110 will be the BIC code for the customer of the NOSTRO account of Payable Bank.

Explanation

Message Type

Message Contents

110

2-70

Receiver

Message Text

Transaction reference number

Number of the Cheque

Date the Cheque was issued

BIC of the customer corresponding to the Nostro A/C of the Liquidation product’s ARC setup

:20:Contract Ref no of the DD/PO transaction

Currency and Amount of cheque :32B: Instrument Currency Instrument Amount

Payee of the Cheque :59: Beneficiary Name

End of Message text/trailer

:21: Instrument Number from the DD Transaction

:30:Instrument Date from DD/PO transaction

Note the following:

During instrument transaction creation process, the system validates the instrument currency (i.e. SI Currency) maintained at instruction level with the local branch currency and if the instrument currency is different from local branch currency then MT110 will be generated.

During Instrument Product Maintenance, the products which are linked to the instrument, message types should be given as DD_ISSUE and MCK_ISSUE to generate DD/PO.

The DD/PO will be generated as per below sample format:

ISSUE BRANCH : _ISSBRN_ _ISSBRNDESC_

_ISSADDR1_

_ISSADDR2_

_ISSADDR3_

PAYABLE AT : _PAYBRN_ _PAYBRNDESC_

_PAYBANK_

Draft No. : _INSTRNO_ _INSTRTYPE_

_INSTRTYPEDESC_

Date : _INSTRDATE_

Amount : _INSTRCCY_ _INSTRAMT_

_INSTRAMTWORDS_

BENEFICIARY: _BENNAME_

_BENADDR1_

_BENADDR2_

_BENADDR3_

_BENADDR4_

_BENADDR5_

2-71

2.8.17 MT 362 (Interest Rate Reset/Advice of Payment)

This message is exchanged by or on behalf of the financial institutions, Party A and Party B, who have agreed to a single or cross currency interest rate derivative transaction, including caps, collars and floors.

This message may be used to: advise details of determination of the floating interest rate(s) advise details of payment of interest at the end of an interest period

Maximum Length: 2000

Mandatory Sequence A General Information

Field Tag Field Name Format Mandatory/Opt ional

21B

30V

30P

82a

87a

83a

94A

22C

23A

21N

15A

20

21

22A

29A

72

New Sequence

Sender's Reference

Related Reference

Type of Operation

Scope of Operation

Common Reference

Identification of the Swap

Contract Number Party A

Contract Number Party B

Effective Date

Termination Date

Party A

Party B

Fund or Beneficiary

Customer

Contact Information

Sender to Receiver

Information

Empty field

16x

16x

4!c

4!c

4!a2!c4!n4!a2!c

10a/5a

16x

16x

8!n

8!n

A or D

A or D

A, D, or J

4*35x

6*35x

O

M

M

M

M

O

O

M

M

M

M

M

O

M

O

O

2-72

30X

30Q

37G

37J

Optional Sequence B Interest Rate/Principal Payable by Party B

Field Tag Field Name Format Mandatory/Opt ional

15B

33F

New Sequence

Calculation Notional Currency and Amount

Empty field

3!a15d

M

M

Period Start Date

Period End Date

Reset Rate

Cap Rate

8!n

8!n

[N]12d

12d

M

O

M

O

37L

37R

37M

Floor Rate

Spread

Total Rate

12d

[N]12d

[N]12d

O

M

M

30F

32H

33E

37N

Payment Date

Currency, Interest Amount

Currency, Principal Exchange

Amount

Details of Interest Rate

8!n

[N]3!a15d

3!a15d

6*35x

M

O

O

O

Optional Sequence C (Net) Amount(s) Payable by Party B

Field Tag Field Name Format

15C

18A

30F

32M

53a

56a

86a

New Sequence

Number of Repetitions

Payment Date

Currency, Payment Amount

Delivery Agent

Intermediary

Second Intermediary

Empty field

5n

8!n

3!a15d

A or D

A or D

A or D

M

M

O

O

O

Mandatory/Opt ional

M

M

2-73

57a Receiving Agent A or D M

37R

37M

30F

32H

33E

30X

30Q

37G

37J

37L

Optional Sequence D Interest Rate/Principal Payable by Party A

Field Tag Field Name Format Mandatory/Optio nal

15D

33F

New Sequence

Calculation Notional Currency and Amount

Empty field

3!a15d

M

M

Period Start Date

Period End Date

Reset Rate

Cap Rate

Floor Rate

8!n

8!n

[N]12d

12d

12d

M

O

M

O

O

37N

Spread

Total Rate

Payment Date

Currency, Interest Amount

Currency, Principal Exchange

Amount

Details of Interest Rate

[N]12d

[N]12d

8!n

[N]3!a15d

3!a15d

6*35x

M

M

M

O

O

O

Optional Sequence E (Net) Amount(s) Payable by Party A

Field Tag Field Name Format

15E

18A

30F

32M

53a

New Sequence

Number of Repetitions

Payment Date

Currency, Payment Amount

Delivery Agent

Empty field

5n

8!n

3!a15d

A or D

M

M

O

Mandatory/Optio nal

M

M

2-74

56a

86a

57a

Intermediary

Second Intermediary

Receiving Agent

A or D

A or D

A or D

O

O

M

2.8.17.1 Processing Incoming MT362

During STP, the system picks up an incoming MT362 message and extracts the following details from Sequence D for auto confirmation:

The currency and interest amount to be paid (Field 32H)

The currency and principal to be exchanged (Field 33E)

The payment due date (Field 30F)

After the above details are extracted, the corresponding interest and principal schedule on that date is compared with the details extracted as mentioned above. The following details are considered for matching:

The schedule due date

The amount of the schedule

The currency of the schedule

The pay and receive flag of the schedule

If the details match, the schedule will be marked as

‘Confirmed’. The same approach is followed for party B whose details are extracted from sequence B of the message. After the message is processed, the message is marked as

‘Processed’. You can view the message status in the incoming browser. After the corresponding schedules are marked as confirmed, they can be viewed in the contract confirmation screen. After confi rmation, ‘Media’ will be updated as ‘SWIFT’ and ‘Authorization Status’ as ‘Auto’ in this screen.

RCON is triggered post confirmation and can be viewed under ‘Contract Online’ screen.

2.9

Generation of MT920 Messages

Oracle FLEXCUBE allows you to generate SWIFT Messages for transactions. MT920 is a transaction message requesting latest information available for the particular account. The request will be to transmit account customer statement message (MT940) or Balance report

(MT941) or Interim statement (MT942) or a customer summary statement (MT950

2.9.1 Generating MT920 Message

You need to generate the MT920 message. You can do this in the

‘Generate MT920’ screen. The screen is as shown below:

2-75

Receiver

In the Generate MT920 screen, you can select the receiver of the message. The system shows only those receivers whose details you have maintained in the customer maintenance with

MT920 as Y.

Reference No.

After providing the receiver details, click ‘P’ button. Based on this the system generates the new reference number

Details

Under Details in the Generate MT920 screen, provide the following details about the chosen receiver:

Customer No

Under

Details, select the required ‘Customer No’ from the options listed. In the list you can find only those customer numbers maintained for the receiver in customer BIC maintenance with

MT920 flag as Y

Account No.

Select the relevant account number of the customer from the available options. In the list, you will find only those Account numbers maintained for the receiver (BIC) and the Account in customer

BIC maintenance.

Message

Select the message requested by the customer here.

Currency

Indicate the preferred currency of the customer.

2-76

Floor Limit

Indicate the debit (D) and credit (C) floor limits of the customer here.

On save and authorization of the Maintenance, system generates the outgoing SWIFT message namely MT920.

If you click

‘Message’ button, the system will display the outgoing MT920 message separately.

2.9.2 Processing of Incoming 920

When the incoming message is MT920 and the requested message is 940 (customer account statement) message, the system sends back the SWIFT Message, MT940 with response.

When the incoming message is MT920 and the requested message is MT941, the system sends back the SWIFT Message, MT941 with response.

When the incoming message is MT920 and the requested message is MT942, the system sends back the SWIFT Message, MT942 with response.

When the incoming message is MT920 and the requested message is MT942, the system sends back the SWIFT Message, MT950 with response.

Thus, the system, which uploads an MT920 message, is also able to generate an outgoing

MT940, MT941, or MT942 Swift Messages

The transliterated message can be viewed in the outgoing browser as,

The message to be transliterated can be viewed in the incoming browser,

2-77

The original message screen is as follows,

The original message for MT940 and MT950 can be viewed from the following screen

2-78

2-79

3. Netting Payments across modules

3.1

Introduction

Oracle FLEXCUBE allows you to

‘net’ contracts pertaining to different modules provided they satisfy certain conditions. The Netting facility is useful at the time of contract settlement. You can opt to net two or more contracts at the time of settlement if the contracts are:

Linked to the same counterparty (customer)

Have the same Value Date

If your bank has signed a netting agreement with the counterparty

Thus if four contracts for a given counterparty settle on the same day and if your bank has signed a netting agreement with the counterparty, then instead of four separate payment messages a single payment message will be sent to the counterparty.

3.1.1 Maintenance required for Netting Payments in Oracle FLEXCUBE

To net entries pertaining to deals involving a specific counterparty in Oracle FLEXCUBE, requires certain basic information to be maintained. The information that needs to be captured includes the following:

Capturing the netting agreement related details

Maintaining netting related information at the contract level

Maintenance pertaining to the Route for settling payments

Maintenance required for FT upload

3.1.2 Capturing the Agreement related details

To net deals in Oracle FLEXCUBE, you must enter into a netting agreement with the concerned counterparty. You can do this through the

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

3-1

These details will be used to net all deals that you enter into with the counterparty.

Customer Number

You must identify the CIF ID assigned to the Counterparty for whom you are maintaining the netting agreement details.

When you choose to net contracts at the beginning of the day, all contracts specified for netting will be netted for every customer for whom you have maintained netting details.

Agreement Reference Number

Each netting agreement record that you maintain should be identified with a unique reference number in Oracle FLEXCUBE. You can specify a unique number to identify each agreement.

Indicating the details of the Agreement

As part of specifying the details of the agreement you will have to capture the following information:

The period for which the netting agreement is valid

The Outgoing FT product, which is to be used to send the payment details to the customer

The netting suspense account into which the entries are to be posted during contract processing

Example

Assume you have entered into three separate FX, MM and DV deals with Cavillieri and Barrett Finance

Corporation (the counterparty). You bank has also signed a netting agreement with the counterparty whereby you have indicated that entries involving contracts for the counterparty should be netted.

As a result, while posting the entries during contract processing, the accounting function will replace the customer account with the netting suspense account and the entries will be posted as follows:

FX

Dr. FXBOT GL a

3-2

Cr. CSA1

MM

a (CSA1 = Cust Suspense Acct)

Dr. CSA1 b (CSA1 = Cust Suspense Acct)

Cr. AssetGL b

DV

Dr. IRS_Bot_GL c

Cr. CSA1 c (CSA1 = Cust Suspense Acct)

The system will not generate payment messages for the three individual contracts. However, during the

EOD/BOD processing a single FT will be generated. The payment message will be sent through this FT. As a result of the FT Contract the following set of entries will be passed.

Dr. Cust Suspense Acct a + c - b

Cr. CustAcct1 a + c - b -- the actual customer account

The netted payment message will be generated Settlement Message Days (maintained in the

Currency Definition screen) before the due date. The Settlement Messages (SGEN) event will be triggered as usual, but the individual payment messages will not be generated for counterparties with whom you have a netting agreement.

3.1.2.1 Specifying Product restrictions for the Counterparty

If you choose not to make the netting feature applicable on transactions involving specific products thereby establishing certain controls you can maintain a Product Restriction list for each counterparty.

To maintain a list of allowed/disallowed products, click on the

‘Product Restriction’ tab in this screen.

3-3

Choosing the list type

You can specify product restrictions in the form of allowed lists or disallowed lists.

If you create an ‘allowed’ list of products, entries involving transactions for the particular counterparty and product combination will be netted. On the other hand, if you maintain a

‘disallowed’ list, the entries involving the respective product and counterparty combination will not be netted.

You can indicate whether you are maintaining an allowed or a disallowed list type by choosing the appropriate option.

3.1.3 Maintaining netting related information at the contract level

In addition to maintaining a netting agreement for each counterparty, you have to specify whether or not the contract is under the netting agreement for each contract involving the counterparty.

You can do so by enabling the Netting option in the Settlements sub-screen of the Contract

Online screen while processing contracts involving the customer.

3-4

The various components (Amount Tags) of the transaction like commission, interest, tax, charges etc will be displayed in this screen. Ensure that you enable this option for each component of the transaction.

Refer section Account Details of Capturing Account Details for explanation on Settlement Details

Screen.

3.1.4 Maintenance pertaining to the Route for settling payments

You can maintain the settlement preferences of a customer or a bank in the

‘Settlement

Instructions Maintenance

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

3-5

You will have to maintain a set of instructions for the Netting (NT) module. While sending the payment message for the netted FT the default settlement route that you have maintained for the parties involved in this module will be used.

Refer section Capturing Settlement Preferences for a Customer for explanation on Settlement

Instruction Screen.

3.2

Generating the netted FT

You can generate the netted FT at any time of the day by executing a batch program. The Netting

Across Modules program is available under the Batch Program option in the Application Browser.

Upon executing this program successfully you will be intimated with the following message:

Netting across Modules Successful

3.2.1 Viewing details of Netted Contracts

You can view details of netted contracts through the

‘Netting Across Modules Detailed’ screen.

You can invoke this screen by typi ng ‘ISDNETNG’ in the field at the top right corner of the

Application tool bar and clicking the adjoining arrow button.

3-6

In this screen, you will be able to view details of all Contracts Under Netting for the following parameters:

The Netting Reference Number

The Customer involved in the transactions

The Value Date of the transactions

The netted amount

The code of the branch in which the transactions were processed

The currency of the transactions

The debit/credit indicator

– indicating whether the amount was debited or credited to the

‘Net’ Account

Querying for details of the Netted contracts

You will also be able to perform queries on the Netted Amount and the Netting Reference

Number through the ‘Netting Across Modules Summary’ screen.

3-7

In this screen, Double Click on the record to view details of the FT contract

3-8

4. Annexure - A - File Formats

4.1

Introduction

This section lists out the upload file formats.

4.2

BIC record upload

As mentioned earlier, Oracle FLEXCUBE allows you to upload the entire BIC directory or individual records like FI and AM. The record Financial Instructions (FI) includes the modified data of all the fields in the BIC directory except the BIC. The Amendments (AM) record contains the modified BIC details.

4.3

Record file formats

The file formats for the FI and AM records is as under:

FI record

Position Description Length Type

1 Tag Identifier 2

Mandatory Data

VARCHAR2 Y

‘FI’

3 Modification

Flag

1 VARCHAR2 Y

‘A’ addition

‘M’ modification

‘D’ deletion

‘U’ unchanged

4 BIC (Bank,

Country &

Location

Code)

8 VARCHAR2 Y Bank code (4 char)

Country code (2 char)

Location code

(2 char)

12 BIC (Branch code)

3 VARCHAR2 Y

15

50

85

Institution

Name

Institution

Name

Institution

Name

35

35

35

VARCHAR2 Y

VARCHAR2 N

VARCHAR2 N

Branch code, with

-

‘XXX’ if no branch code exists

Name (first part)

Name (second part)

Name (third part)

4-1

Position Description Length

120 Branch

Information

35

155

190

225

229

289

324

359

394

429

464

199

534

Branch

Information

City Heading

Subtype indication

Value Added

Services

Extra

Information

Physical address

Physical address

Physical address

Physical address

Location

Location

Location

35

35

4

60

35

35

35

35

35

35

35

35

Type Mandatory Data

VARCHAR2 N Branch specification

(first part)

VARCHAR2 N Branch specification

(second part)

City name VARCHAR2 Y

VARCHAR2 Y

VARCHAR2 N

A subtype can be bank, broker, etc.

20 x 3 char.

Fields indicating the

Value-added

Service Code

VARCHAR2 N

VARCHAR2 N

Specific information

Physical address (first part)

VARCHAR2 N

VARCHAR2 N

VARCHAR2 N

VARCHAR2 N

VARCHAR2 N

VARCHAR2 N

Physical address

(second part)

Physical address (third part)

Physical address (fourth part)

Location (first part)

Location

(second part)

Location (third part)

4-2

Position Description

569

604

639

674

709

744

779

814

Country name 35

Country name 35

POB Number

POB Location

POB Location

POB Location

POB Country name

POB Country name

Length

35

35

35

35

35

35

Type Mandatory Data

VARCHAR2 N Country name

(first part)

VARCHAR2 N

VARCHAR2 N

Country name

(second part)

Post Office Box number

VARCHAR2 N

VARCHAR2 N

VARCHAR2 N

VARCHAR2 N

VARCHAR2 N

POB Location

(first part)

POB Location

(second part)

POB Location

(third part)

POB Country name (first part)

POB Country name (second part)

AM record

The AM record would consist of only the tag identifier, old BIC and the new BIC.. The file format is as follows:

Position Description

1

Length Type

Tag Identifier 2

Mandatory Data

VARCHAR2 Y

‘AM’

3

14

Old BIC

New BIC

11

11

VARCHAR2 Y

VARCHAR2 Y

Old BIC

New BIC

4-3

5. Screen Glossary

5.1

Function ID List

The following table lists the function id and the function description of the screens covered as part of this User Manual.

Function ID Function Description

ISDBICDI

BIC Code Details

ISDBICPU

BIC Upload

ISDIBANP

BICPlusIBAN Maintenance

ISDINSTR

Settlement Instructions Maintenance

ISDISBAN

IBAN Information Maintenance

ISDNETNG

Netting Across Modules Detailed

ISDSRCMD

Multimode Settlement Maintenance

ISDUTBEN

Ultimate Beneficiary Maintenance

ISSBICDI

BIC Code Summary

ISSIBANP

BICPlusIBAN Maintenance Summary

ISSISBAN

IBAN Information Summary

STDNTMNT Netting Agreement Maintenance

5-1

Settlements

[April] [2012]

Version 11.3.1.0.0EU

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200 www.oracle.com/ financial_services/

Copyright © [2012] Oracle Financial Services Software Limited. All rights reserved.

No part of this work may be reproduced, stored in a retrieval system, adopted or transmitted in any form or by any means, electronic, mechanical, photographic, graphic, optic recording or otherwise, translated in any language or computer language, without the prior written permission of Oracle Financial Services Software Limited.

Due care has been taken to make this document and accompanying software package as accurate as possible. However,

Oracle Financial Services Software Limited makes no representation or warranties with respect to the contents hereof and shall not be responsible for any loss or damage caused to the user by the direct or indirect use of this document and the accompanying Software System. Furthermore, Oracle Financial Services Software Limited reserves the right to alter, modify or otherwise change in any manner the content hereof, without obligation of Oracle Financial Services Software

Limited to notify any person of such revision or changes.

All company and product names are trademarks of the respective companies with which they are associated.

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents