2. Settlements Service

2.1 Introduction

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

In Oracle Lending, 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, handles the generation of settlement messages.

This chapter contains the following sections:

2.2 Capturing Settlement Preferences for a Customer

You can maintain the settlement preferences of a customer or a bank in the ‘Settlement Instructions Maintenance Summary’ screen invoked from the Application Browser.

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

 

This section contains the following topics:

2.2.1 Capturing account details

Indicating preferences for an entity means defining the settlement accounts and a detailed settlement route comprising the correspondent accounts and the intermediaries through which the settlement messages are to be generated. The party information you can capture adheres to SWIFT standards. You can maintain the following basic settlement preferences for an entity (counterparty), module, currency, mnemonic, branch, product, and settlement sequence number combination.

While indicating the product code you can choose a specific product code or choose ‘All’ from the option list. However, if you have chosen ‘All’ in the Module field, this field is defaulted to ALL. You are not allowed to change this.

You can specify a unique SSI Mnemonic (Standard Settlement Instruction Mnemonic) for the combination of Counterparty, Counterparty Type, Module, Currency, and Branch combination.

You can define a new sequence number for the settlement instruction you are maintaining. Consequently, you can access this sequence number at the contract level. You can maintain various settlement instructions for each transaction comprising of the same counterparty.

By default, the sequence number generated by the system is zero.

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

If you choose to generate direct debit messages for settlements, the system generates a customer direct debit message or bank direct debit messages depending on the customer type of the counterparty.

Note

If you are defining settlement instructions for a customer related to the FT module you have to indicate the charge account, which is 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.

Subsequently, you need to maintain the transfer type for the settlement instruction specifying whether the transfer is a customer type or bank type. In addition, the Instruction type for both Pay leg and Receive leg has to be maintained for the payment. The available options are Manual, Awaited, Nostro, and Vostro. In addition, as part of settlement instruction you need to maintain the USD clearing network details whether the USD clearing Network is Fedwire, CHIPS Universal or CHIPS participant.

2.2.2 Capturing Message Details

Click ‘Message Details’ from the “Settlement Instructions Maintenance Summary’ to capture message details.

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. Selecting this check box defaults the information in field 72. Leave the box deselected to indicate otherwise.

Regulatory Reporting Details

This field corresponds to field 77B of a SWIFT message. For the receiver or sender, you need to maintain the code (s) for the statuary or regulatory information, which is mandatory as per the rules of the specified country.

2.2.3 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 Summary’ screen.

 

This screen contains fields that mark possible routes of a payment.

Ordering Institution for Payment Message

The ‘Ordering Institution’ in a payment refers to the financial institution of the customer. This field corresponds to field 52a of a SWIFT message.

Ordering Customer for Payment Message

The ‘Ordering Customer’ in a payment refers to the customer ordering the transaction. This field corresponds to field 50a of a SWIFT message.

Ultimate Beneficiary

The ‘Ultimate Beneficiary’ in a payment refers to the party designated by the ordering party as the ultimate recipient of the funds.

If the ‘Chinese Characters in Payment’ box is selected in the ‘Loans and Commitments- Branch Parameters’ screen, then only you can enter the Chinese characters in this field for foreign currency and local currency settlement instructions / accounts and there are not any validations in the system. You need to operationally control it.

You are allowed to enter the information in Chinese or English or a combination of both in this field. If it is a combination, then the system considers it as Chinese and allow up to 35 characters.

 

Receiver’s Correspondent

The ‘Receiver’s Correspondent’ is the branch of the Receiver, or another financial institution, at which the funds are made available to the Receiver.The information you specify here corresponds to Field 54a of a Swift message. You can enter one of the following:

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.

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 any of the following:

 

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:

If the ‘Chinese Characters in Payment’ box is checked in the ‘Loans and Commitments- Branch Parameters’ screen, then only you can enter the Chinese characters in this field for foreign currency and local currency settlement instructions / accounts and there are not any validations in the system. You need to operationally control it.

You are allowed to enter the information in Chinese or English or a combination of both in this field. If it is a combination, then the system considers it as Chinese and allow up to 35 characters.

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.

Receiver Account

The ‘Receiver Account’ is the account number of the beneficiary. This field corresponds to field 58a of a MT202 cover message.

Receiver of Cover

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

Note

For more information about specific parties, refer to the SWIFT manuals.

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.2.4 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 Notices’ section of the ‘Settlements Instructions Maintenance Summary’ screen.

 

Ordering Institution for Receive Notice

The ‘Ordering Institution’ in a payment refers to the financial institution of the customer. This field corresponds to field 52a of a SWIFT message.

Ordering Customer for Receive Notice

The ‘Ordering Customer’ in a payment refers to the customer ordering the transaction. This field corresponds to field 50a of a SWIFT message.

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 any of the following:

2.2.5 Capturing details of parties involved in Direct Debit

You can also capture details of all the DD parties (Debtor and Creditor) involved in a contract.

 

For the DD Parties details, you can specify the following details.

Creditor Bank Details

You can specify the bank details of the creditor.

Debtor Bank Details

You can specify the bank details of the debtor.

Creditor Account Details

You can specify the account details of the creditor.

Debtor Bank Details

You can specify the bank details of the debtor.Receiver of Direct Debit

This field indicates the Recipient of the DD message and the system derives the type of the message to be generated based on this information.

In case the receiver of the DD message is

2.2.6 Maintaining Local Clearing and Cover Details

When you specify settlement instructions for a customer, you can indicate whether payment for local currency transactions is to be effected through 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 Local Clearing; and in the Cover By field, indicate the mode through which cover must be available.

If you indicate payment over a clearing network, you have to specify the account details of the external counterparties (both pay and receive accounts) in the Cover/Clearing tab of the Settlement Instructions screen.

In addition to clearing details, you can also indicate cover for payment through the local clearing network in the Cover/Clearing Details tab in the Settlement Instructions screen by specifying the account details of the cover party. For the counterparty details, you can specify the bank code, account prefix, account and account name.

 

For the cover party account details, you can specify the bank code, account prefix, 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

2.3 Settlement Instructions Sequence

In Oracle Lending, the settlement instructions maintained are resolved in the following sequence:

Level

Sequence No

Counterparty

CCY

Module

Product

Branch

1

Sequence No

Counterparty

CCY

MOD

Product

Branch

2

Sequence No

Counterparty

CCY

MOD

Product

ALL

3

Sequence No

Counterparty

CCY

MOD

ALL

Branch

4

Sequence No

Counterparty

CCY

MOD

ALL

ALL

5

Sequence No

Counterparty

CCY

ALL

ALL

Branch

6

Sequence No

Counterparty

CCY

ALL

ALL

ALL

7

Sequence No

Counterparty

ALL

MOD

Product

Branch

8

Sequence No

Counterparty

ALL

MOD

Product

ALL

9

Sequence No

Counterparty

ALL

MOD

ALL

Branch

10

Sequence No

Counterparty

ALL

MOD

ALL

ALL

11

Sequence No

Counterparty

ALL

ALL

ALL

Branch

12

Sequence No

Counterparty

ALL

ALL

ALL

ALL

13

Sequence No

ALL

CCY

MOD

Product

Branch

14

Sequence No

ALL

CCY

MOD

Product

ALL

15

Sequence No

ALL

CCY

MOD

ALL

Branch

16

Sequence No

ALL

CCY

MOD

ALL

ALL

17

Sequence No

ALL

CCY

ALL

ALL

Branch

18

Sequence No

ALL

CCY

ALL

ALL

ALL

19

Sequence No

ALL

ALL

MOD

Product

Branch

20

Sequence No

ALL

ALL

MOD

Product

ALL

21

Sequence No

ALL

ALL

MOD

ALL

Branch

22

Sequence No

ALL

ALL

MOD

ALL

ALL

23

Sequence No

ALL

ALL

ALL

ALL

Branch

24

Sequence No

ALL

ALL

ALL

ALL

ALL

During the upload of FT contracts, if the offset account for the transactions is not provided in

the upload details, the system resolves the offset account from the settlement instructions maintained for the product, counterparty, currency, branch, and module details of the uploaded transaction.

2.4 Processing Settlements

The Settlement Instructions for a contract or deal can be captured in the ‘Settlements ’ screen. To invoke this screen, click ‘Settlements’ in the Loan and Commitment -Contract Input’ main screen (OLDTRONL) of a module. In this screen, you can capture the following information:

This section contains the following topics:

2.4.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 are 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.

 

The account details that get defaulted include the component and its currency; the SSI Mnemonic specified for the combination of Counterparty, Module, Currency, Product, and Branch involved in the contract, the payment account and its currency; the branch of your bank to which the account belongs; and the exchange rate (in case the component currency is different from the account currency).

Note

For the Loans module only, if a settlement account has been specified, in the settlement instructions for the customer, and a different account has been specified for the loan, the account specified for the loan takes precedence.

2.4.1.1 Specifying Euro-Related Information

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 choose to furnish the ERI value of the amount, you have to enter the following in this screen:

The system defaults to the ERI currency specified for the customer and currency combination. You can change the default ERI currency. The ERI amount that you specify is validated with the Tolerance Limit specified for the ERI currency (in the Currency Maintenance screen).

Cross-currency Settlements of FX deals

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

Example

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

The scenario:

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.

2.4.1.2 Suppressing Settlement Messages

Settlement messages, defined for components that fall due, is generated automatically on authorizing the contract or when you execute the Settlement Generation function at the End / Beginning of day. You can suppress the 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. Simi­larly, if a component is to be received the debit account chosen becomes the receive ac­count in the settlement maintenance.

2.4.1.3 Specifying instruction details for a contact

As part of contract settlement instructions, you can maintain the following:

For a detailed explanation on Instruction Status and Instruction Type, refer to the Money Market user manual under the ‘Specifying settlement instructions for a contract’ section.

2.4.2 Capturing Message Details for a contract

A contract can either be settled through an instrument or a Messaging service (such as SWIFT). The details of the instrument or message have to be specified in the Message Details screen.

The message details that you specify applies only for messages generated through SWIFT. The type of SWIFT message that is generated depends on the parties involved in the contract.

 

Depending on the method in which you want to settle the contract, you should specify either Instrument or Message details.

Instrument details

If you choose 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 is printed on the instrument.

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

RTGS Payment

This option indicates whether or not the payment mode for the contract is RTGS payment. The system validates this option against the following conditions:

If all the above conditions are satisfied, then the contract is considered an RTGS Payment contract and the system checks the RTGS Payment option in this screen. However, you can change this option at the time of contract input if required.

If any of the settlement details are changed, then the system validates this option again at the time of contract input. If the Payment option is resolved to be an RTGS payment, but deselected at the contract input level, then the contract is not considered for RTGS Message processing. Instead an override is displayed during the save operation of the contract.

If the system resolves the payment as non-RTGS Payment but you mark it as RTGS Payment in the contract input screen, then the transaction is not saved.

Message details

For a SWIFT message, you should specify:

Transfer Type

You can specify the Transfer Type as any of the following:

Related Reference Number

You can enter the Related Reference Number for the contract. This field supports a maximum of 16 characters. The Related Reference Number is reflected in Field 21 of the MT202 message. This field is not mandatory.

Details of Charges

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

USD Clearing Network

You can specify whether the USD clearing Network should be:

 

Sender to Receiver Information on Confirmation

The sender to receiver information maintained in the settlement instructions can be defaulted in the Field 72 during the confirmation of messages. Selecting this box defaults the information in Field 72. Leave the box deselected to indicate otherwise.

Regulatory Reporting Details

This field corresponds to field 77B of a SWIFT message. For the receiver or sender, you need to maintain the code (s) for the statuary or regulatory information, which is mandatory as per the rules of the specified country.

2.4.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.

 

Ordering Institution (52a)

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:

Ordering Customer (50a)

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 are allowed to enter details in this field only if you have initiated a customer transfer (MT 103 and MT 102).

Beneficiary Institution (58a)

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 field corresponds to field 58a of SWIFT.

You are allowed to make entries into this field only for Bank Transfers (when the remitter and beneficiary of the transfer are financial institutions – MT 103 or MT 202). Here you can enter either of the following:

Ultimate Beneficiary (59a)

The Ultimate Beneficiary refers to the Customer to whom the contract or deal amount 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 and MT 202).

The number of banks involved in the transfer would, therefore, depend on the:

 

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.

Receiver’s Correspondent (54a)

The Receiver’s Correspondent is the branch of the Receiver or another financial institution at which the funds are made available to the Receiver. This field corresponds to field 54a of SWIFT. You can enter one of the following:

Intermediary Reimbursement Institution (55a)

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 take place.

Intermediary (56a)

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 S.W.I.F.T.

Here you can enter either of the following:

Account with Institution (57a)

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:

Note

For the fields ‘Intermediary ‘and ‘Account with Institution’, if you select the value ‘FW’ from the option list, you can specify only Fedwire values in the next line.

Receiver Account

The ‘Receiver Account’ is the account number of the beneficiary. This field is used to populate Field 58a of a MT202 cover message.

2.4.4 Capturing Receive Notice Details

In the ‘Receive Notice’ section, you can also capture details of all receive parties involved in a contract.

 

Ordering Institution

The ‘Ordering Institution’ in a payment refers to the financial institution of the customer. This field corresponds to field 52a of a SWIFT message.

Ordering Customer

The ‘Ordering Customer’ in a payment refers to the customer ordering the transaction. This field corresponds to field 50a of a SWIFT message.

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.

2.4.5 Capturing Direct Debit Details

In the ‘DD Parties’, you can also capture details of all the DD parties involved in a contract.

 

For the DD Party details, you can specify the details of the creditor and debtor, their bank details and the details on the receiver of the direct debit.

Receiver of Direct Debit

This field indicates the Recipient of the DD message and the system derives the type of the message to be generated based on this information.

In case the receiver of the DD message is

2.5 Enrichment of Settlement Parties

In Oracle Lending, the facility to enrich the data from the contract settlements is provided while construction the SWIFT messages. For all payment messages, you can derive the BIC code out of a customer and use Option A for the SWIFT messages.

The system resolves the settlement parties to derive the BIC and address of the party in the following order:

The following are the fields from which the system resolves the settlement parties to derive the BIC:

Subsequently, the system enriches the settlement parties only for the following messages:

During the enrichment of settlement parties in Oracle Lending, the system resolves the following conditions as described in the table given below:

Condition

Option

Value

Value is present in BIC directory

A

Value

Value is valid account no and Primary BIC is available for the customer

A

Primary BIC

Value is a valid account number and Primary BIC is not available

D

CIF Address

Value is a valid customer no and Primary BIC for the customer is present

A

Primary BIC

Value is valid customer no and Primary BIC for the customer is not present

D

CIF Address

Value is valid short name and Primary BIC for the cus­tomer present

A

Primary BIC

Value is valid short name and Primary BIC for the cus­tomer is not present

D

CIF Address

Value is not a valid BIC or CIF or Short Name

D

Value

If the system is unable to enrich the data into a valid BIC, it uses the Option D that is provided.

2.6 SWIFT messages handled by Oracle Lending

This section contains the following topics:

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

Type of Transfer

Message Type

Customer Transfer

MT 103

Customer Transfer with Cover

MT 103and MT 202

Bank Transfer with Cover

MT 202

Incoming Bank Transfer with Notice to Receive

MT 202 and MT 210

Direct Debits (Customers)

MT 104 and Reverse 103

Direct Debits (Bank type customers)

MT 204 and Reverse 202

2.6.1 Payment Order — MT 202

Message Details

Format

Explanation

Sender

BKAUFNBKXXX

 

Message Type

202

 

Receiver

CITIBKUSNYX

 

Message Text

 

 

Transaction Reference Number

:20:203998988

 

Related Reference

:21:494931/DEV

Field 20 of MT 103

Value date/ Currency code/ Amount

:32A:020426AUD100000,

 

Beneficiary Institution

:58:CITIBKINMU0

Field 57a of S.W.I.F.T.

The bank is Citibank Mum­bai.

End of message text/trailer

 

 

An example for MT 200

You, (Friendly Neighborhood Bank, Sydney) order Citibank, NY to transfer AUD 1 Million from your Nostro account with them, to your Nostro account with HDFC bank, Mumbai.

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

An example for MT 202

In the example for MT 200, if you involve an Intermediary (field 56a of S.W.I.F.T.) then a cover MT 202 is sent to Citibank, Mumbai.

2.6.2 Message Handoff

If the ‘FTI Handoff Required’ box is checked in the ‘LS Branch Parameter’ Screen, then the Swift message for local currencies are handed off to FTI system for China and Taiwan.

The following changes are done in Oracle Lending for the payment message Handoff from Oracle Lending to FTI through MQ.