Settlements User Manual

Settlements User Manual
Settlements User Guide
Oracle FLEXCUBE Universal Banking
Release 12.0.2.0.0
Part No. E49740-01
October 2013
Settlements User Guide
October 2013
Oracle Financial Services Software Limited
Oracle Park
Off Western Express Highway
Goregaon (East)
Mumbai, Maharashtra 400 063
India
Worldwide Inquiries:
Phone: +91 22 6718 3000
Fax:+91 22 6718 3001
www.oracle.com/financialservices/
Copyright © 2007, 2013, Oracle and/or its affiliates. All rights reserved.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed
on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to
the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure,
modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the
hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other
rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or
intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use
this software or hardware in dangerous applications, then you shall be responsible to take all appropriate failsafe, backup,
redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages
caused by use of this software or hardware in dangerous applications.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and
are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may
not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or display any part, in
any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for
interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors,
please report them to us in writing.
This software or hardware and documentation may provide access to or information on content, products and services from third
parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect
to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or
damages incurred due to your access to or use of third-party content, products, or services.
Contents
1.
Preface ...................................................................................................... 1-1
1.1
1.2
1.3
1.4
1.5
1.6
2.
Introduction..............................................................................................................
Audience..................................................................................................................
Documentation Accessibility....................................................................................
Organization ............................................................................................................
Glossary of Icons.....................................................................................................
Related Documents .................................................................................................
1-1
1-1
1-1
1-1
1-2
1-2
The Settlements Service ......................................................................... 2-1
2.1
2.2
2.3
2.4
2.5
structions
2.6
2.7
2.8
Introduction.............................................................................................................. 2-1
Maintaining BIC Directory 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-12
Maintaining Ultimate Beneficiary Details ............................................................... 2-13
Maintaining Multi Mode Settlement Details ........................................................... 2-14
Capturing Settlement Preferences for a Customer................................................ 2-16
2.5.1 Capturing Details of Parties Involved in Payments................................... 2-20
2.5.2 Capturing Details of Parties Involved in Receipts..................................... 2-24
2.5.3 Capturing Cover Details ........................................................................... 2-25
2.5.4 Maintaining Local Clearing Details and Cover Details for Customer Settlement In2-26
2.5.5 Specifying the Default MT 103 Details ..................................................... 2-27
The Sequence in which Settlement Instructions are Resolved ............................. 2-29
Processing Settlements......................................................................................... 2-29
2.7.1 Capturing Account Details ........................................................................ 2-31
2.7.2 Capturing Message Details for a Contract................................................ 2-33
2.7.3 Capturing Party Details............................................................................. 2-37
2.7.4 Default MT 103 Details ............................................................................. 2-42
2.7.5 Amending Settlement Details ................................................................... 2-44
2.7.6 Processing Settlements for Track Receivable or Payable Amount Tags . 2-45
SWIFT Messages Handled by Oracle FLEXCUBE ............................................... 2-45
2.8.1 Payment Message - MT 100 (103) ........................................................... 2-46
2.8.2 MT 100 (Customer Transfer) .................................................................... 2-48
2.8.3 MT 102 (Consolidated Customer Transfer with Cover) ............................ 2-50
2.8.4 MT 200 (Financial Institution Transfer for its Own Account)..................... 2-53
2.8.5 MT 202 (General Financial Institution Transfer) ....................................... 2-53
2.8.6 MT 205 (Financial Institution Transfer Execution) .................................... 2-54
2.8.7 MT 202COV / 205COV ............................................................................ 2-55
2.8.8 MT 210 (Notice to Receive)...................................................................... 2-58
2.8.9 MT 320 (Fixed Deposit Confirmation)....................................................... 2-59
2.8.10 MT 300 (Foreign Exchange Confirmation) ............................................... 2-61
2.9
3.
3.2
Introduction..............................................................................................................
3.1.1 Maintenance required for Netting Payments in Oracle FLEXCUBE ...........
3.1.2 Capturing the Agreement related details ....................................................
3.1.3 Maintaining netting related information at the contract level ......................
3.1.4 Maintenance pertaining to the Route for settling payments .......................
Generating the Netted FT........................................................................................
3.2.1 Viewing Details of Netted Contracts ...........................................................
3-1
3-1
3-1
3-4
3-5
3-6
3-6
Annexure - A - File Formats .................................................................... 4-1
4.1
4.2
4.3
5.
2-61
2-62
2-63
2-64
2-64
2-66
2-67
2-71
2-71
2-72
Netting Payments across modules ........................................................ 3-1
3.1
4.
2.8.11 MT 400 (Advice of Payment) ....................................................................
2.8.12 Payment Message Generation for MT300/320.........................................
2.8.13 MT 756 (Advice of Reimbursement or Payment) .....................................
2.8.14 MT 012 (ACK Status Acknowledgement) .................................................
2.8.15 MT 019 (NAK Status Acknowledgement) .................................................
2.8.16 MT110 (Advise of Cheque).......................................................................
2.8.17 MT 362 (Interest Rate Reset/Advice of Payment) ....................................
Generation of MT920 Messages ...........................................................................
2.9.1 Generating MT920 Message ....................................................................
2.9.2 Processing of Incoming 920 .....................................................................
Introduction.............................................................................................................. 4-1
BIC Record Upload.................................................................................................. 4-1
Record File Formats ................................................................................................ 4-1
Function ID Glossary ............................................................................... 5-1
1. Preface
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:
1.3
Role
Function
Back office clerk
Input functions for contracts
Back office managers/officers
Authorization functions
Product Managers
Product definition and authorization
End of day operators
Processing during end of day/ beginning of day
Financial Controller/Product Managers
Generation of reports
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility
Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
1.4
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
Chapter 5
Function ID Glossary has alphabetical listing of Function/Screen ID's
used in the module with page references for quick navigation
1-1
1.5
Glossary of Icons
This User Manual may refer to all or some of the following icons.
Icons
Function
Exit
Add row
Delete row
Option List
1.6
Related Documents
For further information on procedures discussed in the manual, refer to the Oracle
FLEXCUBE manuals on:

Common Procedures
1-2
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:
2.2

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.
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 ‘ISDBICDE’ 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.
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.
Note
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.
Customer Name
The system displays the name of the specified customer ID based on the details maintained
at ‘Customer Maintenance’ level.
2-2
Relationship
You have to identify the kind of relationship that exists between your bank and the BIC entity.
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 sub-type code is ‘Yes’ or ‘No’ from
the back-end maintenance in the ‘ISTM_SUBTYPE_CODE’ table. It checks this option
whenever the status in the table for the sub-type code is ‘Yes’. You cannot modify this field.
ADB Member
Select a value to indicate membership of the specified BIC code in Asian Development Bank
(ADB), from the adjoining drop-down list. This list displays the following values:

Yes – Select if the BIC code holds a membership in ADB.

No – Select if the BIC code does not hold a membership in ADB.

Not Applicable – Select if the membership is not applicable for this BIC code.
Note
–
The system maintains ‘Not Applicable’ as the default value.
–
If ‘Not Applicable’ is maintained as the status, then the system will not consider the
status for validation.
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.
Note
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.
2-4
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+
Check this box to process MT102+ messages. Selecting this check box also required the
‘Multi Customer Credit Transfer’ checkbox to be selected.
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.
2-5
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

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.
2-6
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-7
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.
2-8
2.2.5
Maintaining Bank Directory Plus
You can view the details of each BankDirectoryPlus file record in the ‘Bank Directory Plus
Maintenance’ screen. To invoke this screen type ‘ISDBKDPL’ in the field at the top right corner
of the Application tool bar and click on the adjoining arrow button.
Record Key
Specify the record key.
The system displays the following based on the record key specified:
Unique Details

Office Type

Parent Office Key

Head Office Key

Legal Type

Legal Parent Key
Group Details

Group Type

Group Parent Key

Institution Status

Cooperative Group Key

ISO LEI Code
Address Details

Institution Name

Branch Info
2-9

POB Number

Street Address 1, 2,3 & 4

City

CPS

ZIP Code

Country Name

ISO Country Code

Time Zone
BIC Details

BIC8

Branch BIC

BIC Code

Chips ID

National ID

Connected BIC
Other Details
2.2.6

Subtype Indicator

Network Connectivity

Branch Qualifiers

Service Codes

SSI Group Key

IBAN Key
Viewing Bank Directory Plus Details
You can view the details maintained in the 'Bank Directory Plus Maintenance' screen using
the 'Bank Directory Plus Summary' screen. You can invoke this screen by typing 'ISSBKDPL'
2-10
in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow
button.
In the above screen, you can base your queries on any or all of the following parameters and
fetch records:

Record Key

Parent Office Key

Legal Type

Office Type

Head Office Key

Legal Parent Key
Select any or all of the above parameters for a query and click ‘Search’ button. The records
meeting the selected criteria are displayed.

Record Key

Office Type

Parent Office Key

Head Office Key

Legal Type

Legal Parent Key

Group Type

Group Parent Key

Institution Status

Cooperative Group Key

ISO LEI Code
2-11
2.2.7

BIC8

Branch BIC

BIC Code

Chips ID

National ID

Connected BIC

Institution Name

Branch Info

POB Number

Street Address 1,2. 3 & 4

City

CPS

ZIP Code

Country Name

ISO Country Code

Time Zone

Subtype Indicator

Network Connectivity

Branch Qualifiers

Service Codes

SSI Group Key

IBAN Key
Maintaining IBAN Plus
You can view the details of each IBANPlus file record in the ‘IBAN Plus Maintenance’ screen.
To invoke this screen type ‘ISDIBNPL’ in the field at the top right corner of the Application tool
bar and click on the adjoining arrow button.
Record Key
Specify the record key.
2-12
The system displays the following based on the record key specified:
2.2.8

Institution Name

Country Name

ISO Country Code

IBAN ISO Country Code

IBAN BIC

Routing BIC

IBAN National ID

Service Context
Viewing IBAN Plus Details
You can view the details maintained in the 'IBAN Plus Maintenance' screen using the 'IBAN
Plus Summary' screen. You can invoke this screen by typing 'ISSIBNPL' in the field at the top
right corner of the Application tool bar and clicking on the adjoining arrow button.
In the above screen, you can base your queries on any or all of the following parameters and
fetch records:

Record Key

Country Name

IBAN ISO Country Code

Routing BIC

Institution Name

ISO Country Code

IBAN BIC
2-13

IBAN National ID
Select any or all of the above parameters for a query and click ‘Search’ button. The records
meeting the selected criteria are displayed.
2.2.9

Record Key

Institution Name

Country Name

ISO Country Code

IBAN ISO Country Code

IBAN BIC

Routing BIC

IBAN National ID

Service Context
Maintaining IBAN Information
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.
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
2-14
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.
Optional Commence Date
Specify the date from when the IBAN structure is an optional requirement.
Mandatory Commence Date
Specify the date from when the IBAN structure is a mandatory requirement.
SEPA
Select the SEPA from the adjoining drop-down list. The options are:
Y - Select ‘Y’ if the IBAN is used in any of the SEPA schemes.
N- Select ‘N’ if the IBAN is not used in the SEPA schemes.
2-15
2.2.10
Viewing IBAN Information
Invoke 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.
In the above screen, you can base your queries on any or all of the following parameters and
fetch records:

Authorization Status

IBAN Country Code

Record Status
Select any or all of the above parameters for a query and click ‘Search’ button. The records
meeting the selected criteria are displayed.

Authorization Status

Record Status

IBAN Country Code

IBAN Country Position

IBAN Country Code Length

IBAN Check Digits Position

IBAN Check Digits Length

Bank Identifier Position

Bank IDentifier Length

Branch Identifier Position

Branch Identifier Length

IBAN National ID Length
2-16

Account Number Position

Account Number Length

IBAN Total Length
Note
The IBAN Check Digit and IBAN Check National ID validations are applicable only if the
IBANPLUS_REQD global parameter value is 'Y'.
2.2.11
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.11.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.
2-17
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.
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 - Select this to upload BIC plus IBAN file.

BankDirectoryPlus - Select this to upload Bank Directory Plus file.

IBANPlus - Select this to upload IBAN Plus file

IBANStructure - Select this to upload IBAN structure file.

BICPLUSIBANIS - Select this to upload BIC plus IBAN structure file.
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.12
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
2-18

Authorize a record

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 are 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.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.
2-19
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.
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.
2-20
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.
Note
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.
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
2-21
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 option-list 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.
For the above combination of Source, Module, Product and Currency, you can maintain
multiple settlement modes and the associated details given below:
2-22
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.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 ‘ISDINSTN’ in the
field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
2-23
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.
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.
2-24
Note
–
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
Counterparty Name
The system displays the name of the specified counterparty based on the details maintained
at ‘Customer Maintenance’ level.
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.
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.
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)
2-25
Note
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.
Note
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.5.0.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 pay 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,
2-26
2.5.1

Other maintenances required to be CLS compliant

The processing involved in the settlement of CLS deals in Oracle FLEXCUBE
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
2-27
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.
Note
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-28
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

The 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

/MANPAY/ - Mandated Payment

/PHON/ - Deal by Phone
2-29

/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 of 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
Note
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.
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.
2-30
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.2
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.
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:
2-31

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.
Note
–
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.5.3
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:
2-32
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.4
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.
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.
External Counterparty Receive Details
The description of the selected bank, where the external counterparty account resides, is
displayed here.
2-33
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.
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
Message
Message
No
No
Yes
Local Clearing
Message
No
Yes
No
Message
No
No
No
Local Clearing
Yes
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.5.5
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.
2-34
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
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.
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.
2-35
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.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:
2.7
Level
Counterparty
CCY
Module
Branch
1
Counterparty
CCY
MOD
Branch
2
Counterparty
CCY
Mod
ALL
3
Counterparty
CCY
ALL
Branch
4
Counterparty
CCY
ALL
ALL
5
Counterparty
ALL
MOD
Branch
6
Counterparty
ALL
MOD
ALL
7
Counterparty
ALL
ALL
Branch
8
Counterparty
ALL
ALL
ALL
9
ALL
CCY
MOD
Branch
10
ALL
CCY
MOD
ALL
11
ALL
CCY
ALL
Branch
12
ALL
CCY
ALL
ALL
13
ALL
ALL
MOD
Branch
14
ALL
ALL
MOD
ALL
15
ALL
ALL
ALL
Branch
16
ALL
ALL
ALL
ALL
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-36
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.
For 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)
2-37
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
–
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.
Account Description
The system displays a brief description on account.
Netting Indicator
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.
2-38
Rate Code
Specify rate code by selecting appropriate rate code frx‘om selection list. Following values are
available:

Buy

Sell

Mid
Note
In case of charges, if charge currency and settlement currency are different, system applies mid rate.
Spread Definition
Select the spread definition from the adjoining drop-down list. The options available are:

Point

Percentage
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.
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.
The final exchange rate = Base Rate +/- Customer Spread (depending on whether it is a Buy
or a Sell deal).
Note
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.
Note
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.
2-39
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.
Negotiated Cost Rate
The system defaults the negotiated cost rate.
Negotiation Reference
The system displays the negotiation reference here.
Generate Message
Enable this option if a payment messages has to be generated for the settlement instruction.
IBAN Account Number
The system displays the IBAN Account Number.Euro Currency and Euro 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).
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’.
For 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
2-40
generation of the settlement message, defined for a component, by clearing the check box in
the ‘Gen Message’ field.
Note
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 Payment Details for a Contract
The details of the payment have to be specified in the ‘Payment Details’ screen.
.
2.7.2.1
Payment By
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)
Note
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.
2-41
Depending on the method in which you want to settle the contract, you should specify either
Instrument or Message details.
Details of Charge
Details of Charge
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
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.
Note
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+.
Details of Payment
Here you can specify information, from the Ordering Party to the Beneficiary Customer, about
the reason for the payment.
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.
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.
2-42
Sender to Receiver Information
Information 1,2,3,4,5 and 6
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.
Clearing Network
Cover details for
local clearing
willbe
capture
Network.
This
clearing
network while
will begendefaulted
Contract
Input and
used Clearing
subsequently
for PC
Product
resolution
erating during
a PC contract.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.
Note
Settlement through instruments is a feature applicable only for the Funds Transfer module
of Oracle FLEXCUBE.
Cover Details
Cover By
Select the cover by as Message or Clearing.
Cover Required
Check this box if cover is required.
RTGS Details
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-43
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 Reimbursement 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.
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
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.
2-44
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)
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.
Note
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
2-45

2.7.3.2
Other identification codes (for example, account number)
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
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
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
2-46
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.
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 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 captured 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 BIC 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
Note
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.
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:
2-47

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.
External Counterparty 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 defaulted with 'Clearing
Network' maintained in local clearing section in settlement instruction. If
2.7.3.3
Local Clearing Details
You can maintain the local clearing details here.
Message Details
Ultimate Bank Code
Select the ultimate bank code from the adjoining option list.
2-48
Sender Receiver Participant
Specify the sender receiver participant.
Additional Identifier
Specify the additional identifier.
SORBNET Specific Details
Payment Code
Specify the payment code.
Additional Information
Specify additional information, if any.
ZUS Transaction
Nip Payer
Specify the nip payer.
Payer Identifier
Specify the payer identifier.
Declaration
Specify the declaration.
Supplement Id
Select the supplement Id from the adjoining drop-down list.
Payment Type
Select the payment type from the adjoining drop-down list.
No of Declaration
Specify the number of declaration.
FFT
Free text 1, 2 and 3
Specify free text, if any.
Repair Reason
Reason 1, 2, 3 and 4
Specify the reason for repair.
Receiver Information
Receiver Name
Specify the receiver name.
Address 1,2 and 3
Specify the address here.
Sender Receiver Information
Information 1, 2, 3, 4, 5 and 6
Specify the sender receiver information here.
2-49
Additional Information
Information 1, 2, 3 and 4
Specify additional information, if any.
2.7.3.4
Other Details
You can maintain the other details here.
Regulatory Reporting Details
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.
Time Indicators
Transaction Code
This is the code for the transaction type. This field corresponds to field 26T of the MT103
message.
Instruction Code Details
Instruction Code 1, 2, 3, 4 and 5
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

REPA

INTC

TELI

SDVA

PHOB
2-50

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:
2.7.4

/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 CETDefault 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.
2-51
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.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.7.6
Processing Settlements for Track Receivable or Payable Amount Tags
While processing a settlement, the system validates marking of an Amount Tag to Track
Receivable or Track Payable Process.
If Amount Tag is marked to ‘Track Receivable’ or ‘Track Payable’ and ‘Eligible for AR-AP
Tracking’ check box is checked for the CIF linked to the Settlement Account, then the system
replaces the Settlement Account with the ‘GL for ARAP’ or ‘Payable GL for ARAP’,
respectively. The GL is defaulted based on the derivation logic maintained at ‘ARAP Code
maintenance’.
If the Customer is not marked for AR-AP Tracking at the Customer Level, then the system
validates for the mapping of the selected GL to the Product & Component combination. If it is
not mapped, then the system displays an override message.
If an ICCF Amount Tag is marked for ‘Track Receivable’ or ‘Track Payable’ and the Settlement
Account is a GL then a record would be created in LQ Module. The AR/AP Code and GL are
defaulted based on the details maintained at AR-AP Code Maintenance level.
2-52
The MIS Information of the contract is defaulted as MIS Information of the record created in
LQ Module.
The following steps are involved for updating the records in LQ module, for LC, BC, FT, PC
and CL contracts:
2.8

When a contract is saved, a record will be posted in LQ module with an ‘Unauthorized’
status and ‘Outstanding’ collection status.

System authorizes the LQ record automatically after a contract is authorized.

If a contract is deleted, then system deletes the corresponding LQ outstanding.

If a contract is reversed, then the system reverses the corresponding LQ outstanding
record.

If the contract is ‘Unauthorized’, then the system does not allow liquidation of LQ record.
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.
2.8.1
Type of Transfer
Message Type
Customer Transfer
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
MT 210
Direct Debits
MT 104
ACK Status
MT 012
NAK Status
MT 019
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.
Note
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-53
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.
Note
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.
32A
Value Date, Currency Code and Amount
50 (Ordering
Customer)
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).
2-54
52a (Ordering
Institution)
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.
53a (Sender’s
Correspondent)
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.
53B
This field gets populated only if there are multiple account relationships between the
sender and the receiver correspondents.
54a (Receiver’s
Correspondent)
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.
55 (Third Reimbursement bank)
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.
56a (Intermediary)
This information maintained for the Intermediary field is defaulted here. You can change it.
57a (Account
With Institution)
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.
59 (Beneficiary
Customer)
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.
70 (Details of
Payment)
The Details of Payment captured in the Settlements screen will be defaulted here.
71A
Information is defaulted from the Charge
Bearer field in the FT Contract screen.
71F
Sender’s Charges.
2-55
71G
Receiver’s Charges.
72 (Sender to
Receiver Information)
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.
Note
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 sender’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
Description
MT100
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.
32A
Value Date, Currency Code and Amount
50 (Ordering
Customer)
This information you have maintained for the
Ordering Customer field in the Other Messages tab of the Settlements screen is
defaulted here.
2-56
52a (Ordering
Institution)
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.
53a (Sender’s
Correspondent)
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.
54a (Receiver’s
Correspondent)
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.
56a (Intermediary)
This information maintained for the Intermediary field is defaulted here. You can change it.
57a (Account
With Institution)
The information maintained for the Account
With Institution field is displayed here. You
have the option of changing it.
59 (Beneficiary
Customer)
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.
70 (Details of
Payment)
The Details of Payment captured in the Settlements screen will be defaulted here.
71A
Information is defaulted from the Charge
Bearer field in the FT Contract screen.
72 (Sender to
Receiver Information)
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.
Note
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.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
2-57

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
M File Reference
Accounting Entry Ref.
23
M Bank Operation
Code
Bank Operation Code
50a
O
Ordering Customer – (A or K)
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.
52a
O
Ordering Institution – (A or B or
C)
This field would be filled up only if the Ordering Institution for all the underlying FT Contracts is same.
26T
O
Transaction
Type Code
This field would be filled up only if the Transaction Type
codes for all the underlying FT Contracts are the same.
77B
O
Regulatory
Reporting
This field would be filled up only if the Regulatory
Reporting for all the underlying FT Contracts are the
same.
71A
O
Details of
Charges
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.
36
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
32B
M
Transaction
Amount
OUR or SHA- Credit Currency and Credit Amount
Ordering Customer (A or K)
This field would be filled up only if the Ordering Customer for the underlying FT Contracts differs.
50a
O
BEN - Credit Currency and (Credit Amount – Sender’s
Charges)
2-58
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
This field would be filled up only if the Transaction
Type codes for the underlying FT Contracts differ.
77B
O
Regulatory
Reporting
This field would be filled up only if the Regulatory
Reporting for the underlying FT Contracts differs.
33B
O
Currency/
Instructed
Amount
This field will be populated only if the Credit Amount
<> 32B
71A
O
Details of
Charges
This field would be based on ‘Charge Whom’ and will
be filled up only if ‘Charge Whom’ for the underlying
FT Contracts differs.
71F
O
Sender’s
Charges
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
Amounts
Sum of all amounts in 32B
71G
O
Sum of
Receiver’s
Charges
Sum of Receiver’s Charges
53a
O
Sender’s Correspondent
Sender’s Correspondent.
54a
O
Receiver’s
Correspondent
Receiver’s Correspondent
72
O
Sender to
Receiver
Information
Payment Details of FT Contract.
2-59
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

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
Description
2-60
MT200
20
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.
21
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.
32A
Value Date, Currency Code, Amount
53B (Sender’s
Correspondent)
Your entry for Our Correspondent in the Settlement Instructions screen is defaulted here.
56a (Intermediary)
Your entry for the Intermediary field in the Settlement Instructions screen is defaulted here.
57a (Account
With Institution)
Your entry against the Account With Institution
field in the Settlement Instructions screen id
defaulted here.
72 (Sender to
Receiver Information)
2.8.5
MT 202 (General Financial Institution Transfer)
All information pertaining to this message should be captured against the amount tag
TRF_AMT.
Message
Type
Field Tag
Description
MT 202
20
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.
2-61
21
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.
32A
Value Date, Currency Code, Amount
52a
(Ordering
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.
57a
(Account
With Institution)
This is field 54 of the corresponding MT103.
58a (Beneficiary
Institution)
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.
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.
Note
In MT103, MT103P and MT202 if the value in field 52 (Ordering Institution) is the same as
the sender’s correspondent, then field 52 will be suppressed during message generation.
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
MT 205
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.
21
Related Reference
32 A
Value Date, Currency Code, Amount
52 a
Ordering Institution
53 a
Sender’s Correspondent
Description
2-62
2.8.7
56 a
Intermediary
57 a
Account With Institution
58 a
Beneficiary Institution
72
Sender to Receiver Information
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
16x
M
21
Related Reference
16x
13C
Time Indication
/8c/4!n1!x4!n
M
32A
Value Date, Currency Code, Amount
6!n3!a15d
O
52a
Ordering Institution
A or D
O
53a
Sender's Correspondent
A, B, or D
O
54a
Receiver's Correspondent
A, B, or D
O
56a
Intermediary
A or D
O
57a
Account With Institution
A, B, or D
M
58a
Beneficiary Institution
A or D
O
72
Sender to Receiver Information
6*35x
----->
O
-----|
End of Sequence A General Information
Mandatory Sequence B underlying customer credit transfer details
M
50a
Ordering Customer
2-63
A, F, or K
O
52a
Ordering Institution
A or D
O
56a
Intermediary Institution
A, C, or D
O
57a
Account With Institution
A, B, C, or D
M
59a
Beneficiary Customer
No letter option or A
O
70
Remittance Information
4*35x
O
72
Sender to Receiver Information
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:

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:
–

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:
–

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:
–

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_COVERL (MT205COV)
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:
2-64
–

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:
–
2.8.7.2
CUST_RTGS_COV (new RTGS COV format, similar to 205COV format)
COVER_RTGS (old RTGS cover format)
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:
–

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:
–

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:
–
2.8.8
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:
–

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:
–

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_COVERL (MT205COV)
COVER_RTGS (old RTGS cover format)
MT 210 (Notice to Receive)
All information pertaining to this message should be captured against the amount tag
TRF_AMT.
Messag
e Type
Field Tag
Description
MT 210
20
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.
2-65
21
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
Account Identification
30
Value Date
21
Related Reference Number.
32B
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.
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.
56a
(Intermediary)
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.
For outgoing MT210, the first line should have number 1 present in option F.
If the BIC of the ordering institution and sending bank are the
same, this field generation in the message is mandatory.
2-66
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.
21
Related Reference Number
22
Code/Common Reference
30
Date Contract Agreed/Amended
31C
Maturity Date of Deposit
32a
Value Date of Deposit, Currency Code. Contract Amount.
33a
Value Date for Change, Currency Code, Principal Amount to
be Transferred.
34a
Next interest Due Date, Currency Code, interest Amount
37a
Interest Field
22A
NEWT/AMND depending on whether the contract is being
booked or amended.
22C
Common Reference Number according to the SWIFT validation rules.
30T
Booking date of the contract
30V
Value Date of the contract
30P
Maturity Date of the contract
32B
Contract Currency and Contract Amount
30X
Next interest date in case of schedules else Maturity Date.
34E
Currency and Interest amount.
37G
Interest Rate
14D
Interest calculation basis in ICCF screen for interest.
LENDING
The information associated with the amount tag PRINCIPAL
is defaulted from the Settlement Instructions screen.
53A/53D
Account holder of the settlement account
56A/56D
Details entered in the intermediary field in the settlement
instruction screen.
57A/57D
Details entered in the Account With Institution field in the
Settlement Instruction screen.
15C
2-67
15D
58A/58D
Details entered in the Beneficiary Institution field in the Settlement Instruction screen.
BORROWING
The information associated with the amount tag
PRINCIPAL_LIQD is defaulted from the Settlement Instructions screen.
53A/53D
Account holder of the settlement account
56A/56D
Details entered in the intermediary field in the settlement
instruction screen.
57A/57D
Details entered in the Account With Institution field in the
Settlement Instruction screen.
58A/58D
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
Details entered in the Intermediary field in the Settlement
Instructions screen are defaulted in this field.
57A/57D
Details entered in the Account With Institution field in the
Settlement Instruction screen are defaulted here.
58A/58D
Details entered in the Beneficiary Institution field in the Settlement Instruction screen are defaulted here.
BORROWING
The information associated with the amount tag PRINCIPAL
is defaulted from the Settlement Instructions screen.
53A/53D
Details entered in the Receiver’s Correspondent field in the
Settlement Instructions screen are defaulted here.
56A/56D
Details entered in the Intermediary field of the Settlement
Instructions screen are defaulted here.
57A/57D
Details entered in the Account With Institution field in the
Settlement Instruction screen are defaulted here.
58A/58D
Details entered in the Beneficiary Institution field in the Settlement Instruction screen.
2-68
2.8.10
MT 300 (Foreign Exchange Confirmation)
Message
Type
Field Tag
Description
MT 300
15A
New Sequence
22A (Scope of
Operation)
NEWT/AMND depending on Contract booking
or Amendment.
22C (Common Reference)
Common Reference Number, according to the
SWIFT validation rules.
30T (Trade Date)
Booking date for the Contract Booking (NEWT)
event. Event date for all other events.
30V (Value Date)
Bought Value Date.
36
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)
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.
2.8.11
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
The details entered in the intermediary field in
the settlement instructions screen.
57a (Receiving
Agent)
The 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
58
The details entered in the Beneficiary Institution field in Settlement Instructions for the
Amount Tag SETBOTAMT
MT 400 (Advice of Payment)
2-69
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
MT400
Field Tag
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.
Note
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.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-70
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
MT 756
MT 910
Field Tag
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.
72
Sender to Receiver Information.
50
This is mandatory and needs to be validated.
52a
This is mandatory and needs to be validated.
56a
This field is populated with the institution from which
sender received the funds. This is applicable only if
the institution is different from the ordering institution.
Note
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-71
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
Sender
BKAUATWWA
The BIC Code assigned to
Bank Austria, Vienna
Message Type
103
Receiver
CITIBKINMU0
2-72
The BIC Code assigned to
Citibank, Mumbai.
Message Text
Sender Reference
:20:494931/
DEV
Bank Operation Code
:23b:CRED
Value date/ Currency/ Interbank settled amount
:
32A:020426N
LG100000,
Field 32 A of SWIFT
Ordering Customer
:50K:Tanya
Agnihotri
Field 50 K of SWIFT
Sender’s Correspondent
:53B:CITIBKU
SNY1
Field 53 B of SWIFT.
Ultimate Beneficiary
:59:Tina Shenoy
Field 59 of SWIFT
Details of Payment
:70: Birthday
Gift
Field 70 of SWIFT
The correspondent bank is
Citibank, New York
Example II - Payment Order — MT 202
Message Details
Format
Sender
BKAUATWWA
Message Type
202
Receiver
CITIBKUSNYX
Explanation
Message Text
Transaction Reference
Number
:20:203998988
Related Reference
:21:494931/DEV
Value date/ Currency code/
Amount
:32A:020426NLG100000,
Beneficiary Institution
:58:CITIBKINMU0
Field 20 of MT 103
Field 57a of SWIFT
The bank is Citibank Mumbai.
End of message text/trailer
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.
2-73
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
Field In Oracle
FLEXCUBE
Corresponding Field in
SWIFT
Entry
Ordering Institution
Field 52a of SWIFT
HDFC, Mumbai
Sender
Bank Austria, Vienna
Intermediary
Field 56a of SWIFT
Citibank, Mumbai
Details of Payment
Field 70 of SWIFT
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 Contents
Message Type
110
Receiver
BIC of the customer corresponding to the Nostro A/
C of the Liquidation product’s ARC setup
Message Text
Transaction reference number
:20:Contract Ref no of the DD/PO transaction
Number of the Cheque
:21: Instrument Number from the DD Transaction
2-74
Date the Cheque was issued
:30:Instrument Date from 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
Note
–
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
Draft No.
Date
Amount
: _PAYBRN_ _PAYBRNDESC_
_PAYBANK_
: _INSTRNO_
_INSTRTYPE_
_INSTRTYPEDESC_
:
_INSTRDATE_
: _INSTRCCY_ _INSTRAMT_
_INSTRAMTWORDS_
BENEFICIARY: _BENNAME_
_BENADDR1_
_BENADDR2_
_BENADDR3_
_BENADDR4_
_BENADDR5_
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
2-75
Maximum Length: 2000
Mandatory Sequence A General Information
Field Tag
Field Name
Format
Mandatory/
Optional
15A
New Sequence
Empty field
M
20
Sender's Reference
16x
M
21
Related Reference
16x
O
22A
Type of Operation
4!c
M
94A
Scope of Operation
4!c
O
22C
Common Reference
4!a2!c4!n4!a2!c
M
23A
Identification of the Swap
10a/5a
M
21N
Contract Number Party A
16x
M
21B
Contract Number Party B
16x
O
30V
Effective Date
8!n
M
30P
Termination Date
8!n
M
82a
Party A
A or D
M
87a
Party B
A or D
M
83a
Fund or Beneficiary Customer
A, D, or J
O
29A
Contact Information
4*35x
O
72
Sender to Receiver Information
6*35x
O
Optional Sequence B Interest Rate/Principal Payable by Party B
Field Tag
Field Name
Format
Mandatory/
Optional
15B
New Sequence
Empty field
M
33F
Calculation Notional Currency
and Amount
3!a15d
M
30X
Period Start Date
8!n
M
30Q
Period End Date
8!n
O
37G
Reset Rate
[N]12d
M
37J
Cap Rate
12d
O
2-76
37L
Floor Rate
12d
O
37R
Spread
[N]12d
M
37M
Total Rate
[N]12d
M
30F
Payment Date
8!n
M
32H
Currency, Interest Amount
[N]3!a15d
O
33E
Currency, Principal Exchange
Amount
3!a15d
O
37N
Details of Interest Rate
6*35x
O
Optional Sequence C (Net) Amount(s) Payable by Party B
Field Tag
Field Name
Format
Mandatory/
Optional
15C
New Sequence
Empty field
M
18A
Number of Repetitions
5n
M
30F
Payment Date
8!n
M
32M
Currency, Payment Amount
3!a15d
M
53a
Delivery Agent
A or D
O
56a
Intermediary
A or D
O
86a
Second Intermediary
A or D
O
57a
Receiving Agent
A or D
M
Optional Sequence D Interest Rate/Principal Payable by Party A
Field Tag
Field Name
Format
Mandatory/
Optional
15D
New Sequence
Empty field
M
33F
Calculation Notional Currency
and Amount
3!a15d
M
30X
Period Start Date
8!n
M
30Q
Period End Date
8!n
O
37G
Reset Rate
[N]12d
M
37J
Cap Rate
12d
O
37L
Floor Rate
12d
O
2-77
37R
Spread
[N]12d
M
37M
Total Rate
[N]12d
M
30F
Payment Date
8!n
M
32H
Currency, Interest Amount
[N]3!a15d
O
33E
Currency, Principal Exchange
Amount
3!a15d
O
37N
Details of Interest Rate
6*35x
O
Optional Sequence E (Net) Amount(s) Payable by Party A
Field Tag
Field Name
Format
Mandatory/
Optional
15E
New Sequence
Empty field
M
18A
Number of Repetitions
5n
M
30F
Payment Date
8!n
M
32M
Currency, Payment Amount
3!a15d
M
53a
Delivery Agent
A or D
O
56a
Intermediary
A or D
O
86a
Second Intermediary
A or D
O
57a
Receiving Agent
A or D
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,
2-78
they can be viewed in the contract confirmation screen. After confirmation, ‘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.
To invoke this screen, type ‘MSDMT920’ in the field at the top right corner of the application
toolbar and click the adjoining arrow button.
Specify the following details:
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:
2-79
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.
Dr/(Dr and Cr) Floor Limit
Specify the debit floor limit of the customer. If the credit floor limit is not separately specified,
this will indicate both the debit and the credit floor limits.
The system will pick the debit/credit transactions above this limit for customer account
statement report.
This is mandatory for MT942 message type.
Cr Floor Limit
Specify the credit floor limit of the customer. The system will pick the credit transactions above
this limit for customer account statement report.
If you specify the credit floor limit, you must also specify the debit floor limit. However, if you
do not specify the credit floor limit, the system will consider the limit specified in the field ‘Dr/
(Dr and Cr) Floor Limit’ for both credit and debit floor limits.
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.
2-80
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:
3.1.2

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
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
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
3-2
Dr
.
FXBOT
GL
a
Cr
.
CSA1
a (CSA1 = Cust Suspense Acct)
MM
Dr
.
CSA1
b (CSA1 = Cust Suspense Acct)
Cr
.
AssetG
L
b
DV
Dr
.
IRS_Bot_G
L
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
Note
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 ‘ISDINSTN’ in the
field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
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.
3-5
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 message as ‘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 typing ‘ISDNETNG’ in the field at the top right corner
of the Application tool bar and clicking the adjoining arrow button.
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-6
In this screen, Double Click on the record to view details of the FT contract
3-7
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:
4-1
FI record
Positio
n
Description
Length
Type
Mandator
y
Data
1
Tag Identifier
2
VARCHAR
2
Y
‘FI’
3
Modification
Flag
1
VARCHAR
2
Y
‘A’ addition
‘M’ modification
‘D’ deletion
‘U’ unchanged
4
BIC (Bank,
Country &
8
VARCHAR
2
Y
Bank code (4
char)
Country code
(2 char)
Location
Code)
Location code
(2 char)
12
BIC (Branch
code)
3
VARCHAR
2
Y
Branch code,
with
- ‘XXX’ if no
branch code
exists
15
Institution
Name
35
VARCHAR
2
Y
Name (first
part)
50
Institution
Name
35
VARCHAR
2
N
Name (second
part)
85
Institution
Name
35
VARCHAR
2
N
Name (third
part)
120
Branch Information
35
VARCHAR
2
N
Branch specification (first
part)
155
Branch Information
35
VARCHAR
2
N
Branch specification (second
part)
190
City Heading
35
VARCHAR
2
Y
City name
225
Subtype indication
4
VARCHAR
2
Y
A subtype can
be bank, broker,
etc.
4-2
229
Value Added
60
VARCHAR
2
Services
N
20 x 3 char.
Fields indicating
the
Value-added
Service Code
289
Extra Information
35
VARCHAR
2
N
Specific information
324
Physical
address
35
VARCHAR
2
N
Physical
address (first
part)
359
Physical
address
35
VARCHAR
2
N
Physical
address (second part)
394
Physical
address
35
VARCHAR
2
N
Physical
address (third
part)
429
Physical
address
35
VARCHAR
2
N
Physical
address (fourth
part)
464
Location
35
VARCHAR
2
N
Location (first
part)
199
Location
35
VARCHAR
2
N
Location (second part)
534
Location
35
VARCHAR
2
N
Location (third
part)
569
Country
name
35
VARCHAR
2
N
Country name
(first part)
604
Country
name
35
VARCHAR
2
N
Country name
(second part)
639
POB Number
35
VARCHAR
2
N
Post Office Box
number
674
POB Location
35
VARCHAR
2
N
POB Location
(first part)
709
POB Location
35
VARCHAR
2
N
POB Location
(second part)
744
POB Location
35
VARCHAR
2
N
POB Location
(third part)
779
POB Country
name
35
VARCHAR
2
N
POB Country
name (first part)
814
POB Country
name
35
VARCHAR
2
N
POB Country
name (second
part)
4-3
AM record
The AM record would consist of only the tag identifier, old BIC and the new BIC.. The file
format is as follows:
Positio
n
Description
Lengt
h
Mandator
y
Data
1
Tag Identifier
2
VARCHAR
2
Y
‘AM’
3
Old BIC
11
VARCHAR
2
Y
Old BIC
14
New BIC
11
VARCHAR
2
Y
New
BIC
Type
4-4
5. Function ID Glossary
I
ISDBICDE ............................. 2-1
ISDBICPU ........................... 2-18
ISDIBANP ............................. 2-7
ISDINSTN ............................. 3-5
ISDISBAN ........................... 2-14
ISDNETNG ........................... 3-6
ISDSRCMD ........................ 2-21
ISDUTBEN ......................... 2-19
ISSBICDI .............................. 2-5
ISSIBANP ............................. 2-7
S
STDNTMNT .......................... 3-1
5-1
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