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:
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:
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.
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.
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.
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:
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
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 |
In Oracle Lending, the settlement instructions maintained are resolved in the following sequence:
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.
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:
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.
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.
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. Similarly, if a component is to be received the debit account chosen becomes the receive account in the settlement maintenance.
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.
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:
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.
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.
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.
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
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 customer present |
A |
Primary BIC |
Value is valid short name and Primary BIC for the customer 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.
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 |
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 Mumbai. |
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.
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.