5. Processing Funds Transfer

5.1 Introduction

A Funds Transfer (FT) contract is a transaction whereby funds are moved from the account of one party (called the remitter) to another party (called the beneficiary). Such movement of funds may involve a sequence of events, but is treated as one contract.

For example, if a customer of Berliner Bank, instructs them to pay Pounds Sterling to Midland bank, London into the account of Mr. Silas Reed. The sequence of the events that will follow, to effect the transfer can be considered an FT contract.

An FT Contract would therefore require information on:

Under each Product that you have defined, you can enter specific FTs based on the needs of your customer. Each of these will constitute a contract. While products are general and serve to classify or categorize funds transfers, contracts are customer specific and represent the actual funds transfers that you are involved in. The attributes that you define for a product will be inherited by all contracts linked to the product. While some of these attributes (for instance the exchange rate) inherited from a product can be changed when a contract is entered involving the product, there are some attributes (such as accounting treatment) that cannot be changed when the contract is entered.

This chapter contains the following sections:

5.2 Entering Details of Funds Transfer

Through the screens that follow in this section you can initiate all the three major types of FT’s (incoming, outgoing and internal).

You can choose to enter the details of a transfer either by:

To enter the details of a contract, you need to just enter a product code and a few details about the beneficiary and the remitter. Depending on the product code that you select, many of the fields will be defaulted. You can over write some of these defaults to suit the FT that you are processing. After specifying the details, you can save the record. In case of internal transfer when you are saving the records, the system checks whether the accounts mentioned in the ‘from’ and ‘to’ leg of the transaction belong to the same netting group or not. If they belong to the same netting group, the accounting entries will not be posted. Instead the transaction will be logged for the netting batch. The system will automatically place an amount block on the debit account. However, for the credit account, the amount will be reflected only after the netting batch.

On authorisation, the transaction will be made available for the netting batch if logged for netting batch.

Refer the section ‘Maintaining Netting Group’ in the chapter ‘Accounts for Inter-Branch Transactions’ in the Core Services User Manual for further details about netting.

5.3 Specifying FT Contract Details

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

Click the ‘New’ button on the application toolbar.

Enter valid inputs into all the mandatory fields, or you will not be able to save the contract. After you have entered all the details of a funds transfer, save the contract. To save a contract, Select ‘Save’ from the Actions menu in the Application tool bar or click save icon.

At the time of saving a funds transfer contract, the contract details should be passed on to the FATCA accounts and obligations maintenance. The details should be passed on if the customer who will be the beneficiary of the funds transfer has a reportable FATCA classification and if the product code used to book the funds transfer contract is present in the FATCA products, account class and instruments maintenance.

If you have multi branch operation rights, you can create new transactions for a different branch. However, the system will not allow you to query or authorize a transaction which is already created in another branch.

5.4 Description of FT Contract Details Screen

The FT Contract Detailed screen as it appears, contains a header and a footer containing fields that are specific to the contract you are entering. Besides these, you will also notice four tabs and a vertical array of icons, along the lines of which you can enter details of a transfer. Contract details are grouped into various screens according to the similarities they share.

Product

This is the product that is involved in the contract you are entering. Enter the code of an authorized product defined through the Product definition table. Select the product code of the product to which you want the contract to be linked. The contract will inherit all the attributes of the product you have selected.

To facilitate fast input, you need to input the product code. Click ‘P’ button placed next to the Product Code field. The system displays the details of primary keys. Depending on the product code, the system defaults the values against many fields.

The default values will be displayed in the screens that correspond to the four tabs on the ‘Funds Transfer Contract Input’ screen.

Product Description

Based on the product you have chosen, the system displays the description of the product.

Contract Reference Number

As you click ‘P’ button, the system generates the reference number sequentially. This number tag is used to identify the FT contract you are entering, it is also used in all the accounting entries and transactions related to this contract. Hence the system generates a unique number for each contract.

The contract reference number is a combination of a three-character branch code, a four-character product code, a five-digit Julian Date and a four-digit serial number. The Julian Date has the following format:

‘YYDDD’

Here, YY stands for the last two digits of the year and DDD for the number of day (s) that has/have elapsed in the year.

For example,

January 31, 1998 translates into the Julian date: 98031. Similarly, February 5, 1998 becomes 98036 in the Julian format. Here, 036 is arrived at by adding the number of days elapsed in January with those elapsed in February (31+5 = 36).

User Reference

Enter a reference number for the contract. The contract will be identified by this number in addition to the ‘Contract Reference No’ generated by the system. This number should be unique and cannot be used to identify any other contract. By default, the Contract Reference No. generated by the system will be taken as the User Reference No.

Source Reference Number

This is the reference number of the source from which the FT contract was uploaded.

Message Reference Number

This is a unique message identification number that will be used to identify an incoming message coming from an external system. This is defined as the ICN number. On upload of an incoming message into Oracle FLEXCUBE, this number, given by the external system, will be stored in Oracle FLEXCUBE and passed on to the contract generated as a result of the incoming message. If the incoming message results in an outgoing message, the ICN number will be linked to the outgoing message also.

This number will help you in creating a relationship between the incoming message, the resultant contract in Oracle FLEXCUBE, and the outgoing message, if any.

For instance, if an incoming MT103 results in an FT transaction, then ICN number of the incoming MT103 will be linked to the FT contract generated due to the upload of the incoming payment message.

If an Incoming message results in an outgoing contract (outgoing message), Oracle FLEXCUBE will store the External reference number (ICN Number) at the following levels.

The external reference number will also double up as the related reference number in Field 21 of the bank transfer message or MT 202. In the Funds Transfer Contract Details screen, this field will be enabled for Bank Transfer Type product. The value will be validated for ‘/’ at the start, ‘/’ at the end or ‘//’ in the value.

The following tags under MT 202 message will support a clearing code ‘PL’:

The details of these messages will be stored in data store and will be used during message validation.

Note

This field should not have ‘/’ at the start or end or ‘//’ in the value.

Transaction Type Code

Specify the transaction type code.

Source Code

The system displays the source code of the source from which the FT contract was uploaded.

Instruction Code

Select the instruction code from the adjoining option list.

Book Date

Specify the date of booking.

Version Number

Select the version number

5.4.1 Body of Screen

The FT Contract Screen is designed to contain four tabs along the lines of which you can enter details of the contract. The four tabs are:

Main

Click this tab to enter vital details of a contract. This screen, along with its fields, has been detailed under the head Processing a Funds Transfer.

Other Details

Click this tab to set the preferences and specify other details. The details of this tab have been explained under the head ‘Capturing Other Details’.

Settlement Details

Click this tab to specify the details pertaining to regulatory reporting and envelope. You can specify the details on this screen if you have checked the option ‘Remit Messages’ in ‘Product Preferences’ screen.

Settlement Route

Click this tab to view a screen which depicts the route that a transfer will take before it actually reaches the ultimate beneficiary. The details of this screen have been detailed under the head Viewing the settlement route of a transfer.

On the contract detailed screen you will notice a vertical toolbar. The buttons on this toolbar enable you to invoke a number of functions that are vital to the processing of a transfer. These buttons have been briefly enlisted below.

Settlement

Click this button to invoke the Settlement screens. A transfer is settled based on the settlement details that you specify. This has been dis­cussed in the Settlements manual.

MIS

Click this icon to define MIS details for the transfer

Charges

This button invokes the Charges, Commissions and Fees (ICCF) ser­vice. On invoking this function you will be presented with a screen where the ICCF rate, amount, currency, waive charge Y/N parameter can be specified.

In the Charges and Fees manual you will find the entire procedure for maintaining charge rules. It also deals with the linking of a charge scheme to a product and the application of the scheme on a transfer.

Events

Click this button to view details of the events in the life cycle of the transfer you are processing.

Tax

This button invokes the Tax services. On invoking this function you can define the tax scheme that is applicable to the transfer.

The Processing Tax manual details the entire procedure of maintain­ing tax rules and schemes. It also deals with the linking of a tax scheme to a product and the application of the scheme on a transfer.

Advices

Click on this button to suppress or prioritize the advices that are to be generated for a contract. The details of the advices screen have been detailed under the head ‘Specifying advices for a transfer’.

Fields

Click on this icon to invoke the User Defined Fields screen.

Charge Claim

Click this button to specify details for the generation of a Charge Claim Advice (MT 191).

Change Log

If a contract has more than one version, you can use this screen to identify the details that have been changed.

Customer Cover Details

Click this button to specify or view all details related to the new COV format of customer cover.

All Messages

Click this button to view all messages generated for a particular contract.

Project Details

Click this button to capture project details if the beneficiary account is a Trust account.

Duplication Details

Click this button to view the details of duplicate contracts.

After you have made the required mandatory entries and saved the record, your User ID will be displayed at the bottom of the screen. The date and time at which you save the contract will be displayed in the Date Time field.

A user bearing a different User ID should authorize a contract that you have entered before the EOD is run. Once the contract is authorized the Id of the user who authorized the contract will be displayed. The status of the contract will be marked as Authorized.

Click ‘Exit’ button to exit the screen. You will return to the Application Browser.

5.5 Funds Transfer

This section contains the following topics:

5.5.1 Processing Funds Transfer

While defining a product, you have defined a broad outline that will be applicable to all transfers involving it. While processing a transfer, you need to enter information that is specific to the transfer. This information is captured through the Funds Transfer Contract Input – Main screen. From the Funds Transfer Contract Input screen, click the tab titled Main to define important contract details.

The entries that you make to the various fields on this screen depend on whether the funds involved in the contract are incoming, outgoing, or internal. Details of information that can captured through the ‘FT Contract Main’ screen have been detailed below.

5.5.2 Specifying Details for Debit Leg of Transfer

Debit Currency

Specify the currency of the remitter’s account. You can choose a valid currency code from the list of values that is available.

If you do not specify the debit currency, the currency of the account entered in the Remitter Account field will be taken as the debit currency for the transfer. However, if you indicate only the GL of the remitter account and not the account itself in the account field, input into the currency field becomes mandatory.

Debit Branch

If the account of the remitter is in a branch different from your branch, enter the code of that branch. Choose a branch code from the adjoining option list.

This field will be defaulted with the branch code of your bank.

Note

If you have specified an account that uses an account class that is restricted for the prod­uct, an override is sought.

Debit Account

Specify the account number of the remitter i.e., the account to be debited for the transfer amount. This account number should exist in the list of accounts maintained for the branch you had specified in the ‘Branch’ field.

If you are processing an incoming transfer, enter the account of the bank from which your bank has received funds (typically this will be your nostro account in the currency of the transfer). If it is an outgoing transfer, specify the account of the Ordering customer (the ordering customer of your bank). If the remitter is your bank itself, you can specify just the GL of the account. The appropriate account will be picked up by the system, in the currency of the transfer (the currency you specified in the currency field).

To view the joint holder’s details of an account and the mode of operation maintained at the account level, place the cursor on the Debit Account field and press Ctrl+J. The system displays the ‘Joint Holder’ screen.

For more information on the ‘Joint Holder’ screen refer to the section ‘Joint Holder Maintenance’ in the Core User Manual.

Debit Account Description

The description corresponding to the debit account selected is displayed here. If the debit account number keyed in has only one value matching it in the option list, then system will not open the option list on tab out and the description of the debit account will be automatically displayed.

Debit Amount

In this field, enter the amount that is being transferred. This amount is taken to be in the same currency indicated in the previous field. In the case of incoming transfers, this will be the transfer amount indicated in the event definition by the amount tags TFR_AMT. In the case of outgoing transfers, the amount that you enter here will be corresponding to the amount tag AMT_EQUIV, since in an outgoing transfer the actual transfer amount is the amount that is being transferred to the Beneficiary.

On saving the transaction after entering all the required details in the system, the system validates the value of the debit amount against the following:

If the transaction currency and the limit currency are different, then the system converts the amount financed to limit currency and checks if the same is in excess of the product transaction limit and user input limit. If this holds true, the system indicates the same with below override/error messages:

Debit Value Date

This is the date on which the debit leg of the funds transfer becomes effective, i.e., the value date with which the remitter’s account is debited. This date must be earlier than or same as the credit date.

If you do not enter a debit value date, the system defaults the system date (today’s date).

The generation time of an outgoing transfer effected directly in the FT module, through settlements of any other module or on account of a straight through process should be checked against the cut-off time defined for the currency involved in the transfer.

If the system time at the time of message generation for Outgoing transfers is beyond the cut-off time, the value date of the transfer is amended according to the number of days to be added.

Debit Spread

The system displays the number of spread days maintained in the ‘Value Date Spread Detailed’ screen for a customer, product and currency.

Debit Spread Date

The system displays the debit spread date for product, customer and currency in this field. It is derived after adding the spread days to the debit value date maintained in ‘Value Date Spread Details’ screen.

5.5.3 Specifying Details for Credit Leg of Transfer

Credit Currency

Specify the currency in which the beneficiary is to be credited. If you do not enter a credit currency, the currency of the account entered in the ‘Credit Account’ field will be defaulted.

It is mandatory for you to enter a credit currency if you have indicated a GL as the credit account. You can choose a valid currency from the list of values available for this field.

Credit Branch

Enter the branch to which you are crediting funds (i.e.) the branch into which you are crediting the transfer amount, on behalf of the Ultimate beneficiary. You can select a valid branch code from the adjoining option list.

Note

If you have specified an account that uses an account class that is restricted for the prod­uct, an override is sought.

Credit Account

This is the account that will be credited with the transfer amount. For an outgoing transfer it refers to the next bank in the chain (typically your nostro in that currency), for the movement of funds. Depending on the settlement route the funds will in turn be transferred to the next bank in the chain before the ultimate beneficiary is paid. For an incoming transfer this will be ultimate beneficiary’s account in your bank. If you specify a Trust account in this field, you will have to specify project related details in the ‘Project Details’ sub-screen by clicking ‘Project Details’ button. If you do not capture project details, the system will display an error message while saving.

To view the joint holder’s details of an account and the mode of operation maintained at the account level, place the cursor on the Credit Account field and press Ctrl+J. The system displays the ‘Joint Holder’ screen.

For more information on the ‘Joint Holder’ screen refer to the section ‘Joint Holder Maintenance’ in the Core User Manual.

Credit Account Description

The description corresponding to the credit account selected is displayed here.. If the credit account number keyed in has only one value matching it in the LOV, then system will not open the LOV on tab out and the description of the credit account will be automatically displayed.

Credit Amount

Indicate the amount that is to be credited to the beneficiary account. If you are effecting an outgoing cross currency transfer, you need to only enter the credit amount; the other component of the transfer, that is, the debit amount will be derived based on the exchange rate that you specify.

In the case of incoming transfers, the amount that you enter in this field will correspond to the amount tag AMT_EQUIV (the equivalent amount in the remitter’s account currency), while in the case of outgoing transfers, the amount that you enter here will be corresponding to the amount tag TFR_AMT (representing the actual amount that is being remitted.

On saving the transaction after entering all the required details in the system, the system validates the value of the debit amount against the following:

If the transaction currency and the limit currency are different, then the system converts the amount financed to limit currency and checks if the same is in excess of the product transaction limit and user input limit. If this holds true, the system indicates the same with below override/error messages:

Transaction amount is in excess of the input limit of the user

Credit Value Date

This is the value date with which the Beneficiary’s account is to be credited. The credit value date is in reality the value date (transaction date) of the transfer. This date must be later than or equal to the debit date.

The system defaults the value date as explained below:

Credit Spread

The system displays the number of spread days maintained for a customer, product and currency as specified in the ‘Value Date Spread Detailed’ screen.

Credit Spread Date

The system displays the credit spread date for product, customer and currency in this field. It is derived after adding the spread days to the credit value date maintained in ‘Value Date Spread Details’ screen.

IBAN for the debit and credit accounts

The IBAN or International Bank Account Number is a unique account number that is used to identify a customer’s account in a financial institution internationally.

International Bank Account Numbers in your bank are generated in the format of the account mask that you specify in the IBAN Masks section of the Branch Parameters.

You may need to provide the IBAN for the debit and credit accounts involved in a funds transfer transaction.

Debit IBAN

In this field, indicate the IBAN corresponding to the debit account that you have entered for the transaction.

Credit IBAN

In this field, indicate the IBAN corresponding to the credit account that you have entered for the transaction.

Virtual Account

Specify the virtual account number in this field. Based on your input in the ‘Virtual Account Code’ field and ‘Credit Currency’ fields, the physical account is populated in the ‘Credit Account’ field. If no physical account is mapped to the virtual account, then the default physical account linked to the virtual account is derived.

Virtual Account Name

The account name of the virtual account number is displayed in this field.

5.5.3.1 Specifying Exchange Rate Details

The system ascertains the CIF ID based on the debit (for outgoing customer transfers) or credit account (for incoming customer transfers) that you specify. This, along with your specification of the Currency Pair and the Value Date for the transaction, enables the System to automatically assign the exchange rate that is to be used for the FT deal, if currency conversion is involved.

The Exchange Rate applicable for the transaction = Base Rate +/- Customer Spread (depending on whether it is a Buy or a Sell).

The Base Rate is derived from the Mid Rate and the Buy/Sell Spreads that you maintain for the currency pair in the exchange rate maintenance table. The system displays the rate type based on the specifications defined in the product to which the contract is linked.

Similarly, 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 tenor for an FT contract is zero (0) – therefore, you need to maintain Customer Spread for zero tenor in the Customer Spread Maintenance screen.

If 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 – as well as the spread code are displayed based on the specifications defined for the product to which the contract is linked.

Note

For a customer availing any Relationship Pricing scheme, the customer specific exchange rate gets defaulted here, on clicking the ‘Enrich’ button.

FX Contract Reference

Specify the FX Contract Reference number you need to link to the FT contract, for the currency pair. The adjoining option list displays a list of valid FX contract reference number. Select the appropriate one.

If you specify the FX Contract Reference number, you will not be allowed to specify Rate Date and Rate Serial. You cannot Link FX Contract to the FT contract, if 'Split Dr/Cr Liquidation' check box is checked at FT product level

Rate Reference

The Rate Reference for the currency pair can be selected from the option list provided. If you specify the Rate Reference, you will not be allowed to specify Rate Date and Rate Serial.

Rate Date

Rate Date is used for picking up the exchange rate for the currency pair involved in the transaction and is applicable only in the case of cross currency transactions.You need to specify the Rate Date for the currency pair. The Rate Date must be less than or equal to the application date. If you specify Rate Date and Rate Serial, you will not be allowed to specify Rate Reference.

Rate Serial

You can specify the Rate Serial for the Rate Date you have entered. All the rate serials existing for the selected Rate Date will appear for selection. Select a Rate Serial from the option list provided. If you have specified Rate Date and Rate Serial, you cannot specify Rate Reference.

Validations for the Rate Date, Rate Serial and Rate Reference

You cannot specify Rate Date and Rate Serial and Rate Reference simultaneously. You can specify either Rate Reference or Rate Serial and Rate Date. To choose Rate Reference, select from the option list provided. This list will show all active spot FX contracts for the same currency pair as the FT transaction. The currency pair is determined based on the product type of the FT.

Upon choosing the FX contract, the system will default the Exchange Rate of the FX deal as the Base Rate as well as the Exchange Rate for this FT contract. If the Rate Reference is chosen, then no Spread will be applied to the Exchange Rate. The System will take the Exchange Rate of the FX contract as it is. There will not be any variance validation in this case.

If you specify the Rate Date and Rate Serial, then system will look into the Exchange Rate Maintenance and get the rate for the combination. If the Rate Serial number is not present, the system will throw up an error saying the Rate for the Serial Number does not exist. If the Rate Serial Number and Rate Date are entered, then the base rate will be defaulted with the Rate for this combination. In addition to this, the Customer Spread and Product Spread will be applied and the Exchange Rate will be arrived at.

The Rate Serial will be used only if the transaction amount is less than the limit defined for a currency pair. The Funds Transfer Contract Input will default the Rate only if the transaction amount is less than the maximum amount defined for the Rate Code maintained at the FT product level. If the amount is more than the specified amount, then the system will not default the Rate. Instead, it will force you to enter the Rate. If you enter the Rate, the system will not add the Customer Spread, as this will be the final Exchange Rate for the contract.

The rate variance validation will also be done only if the Transaction Amount is less than the Maximum Amount defined for the Rate Code maintained at the FT product level. If the amount is more than the specified amount, the system will not perform rate variance validation. Instead, there will be an override to specify that the transaction amount is greater than the maximum amount for rate variance check.

For more details on customer specific exchange rates, refer the section titled ‘Specifying Pricing Benefit Details’ in Relationship Pricing user manual.

5.5.3.2 Specifying Transaction Details

Local Currency Equivalent

The system displays the local currency equivalent of the transfer amount.

Charge Bearer

There are obvious costs involved in transferring funds from one location to another. You need to indicate who will actually bear these service charges. You can select an option from the option list that is available. The options available are:

This specification is inherited from the specification involving the product used by the contract. It can be changed for a specific FT only if such a change is allowed in the preferences for the product.

Message As Of

Specify the date as of when the messages are to be generated.

Rate As Of

Specify the date as of when exchange rates should be picked up and applied to the components of a transfer.

Accounting As Of

Specify the date as of when accounting entries are posted.

Message Date

Specify the message date.

Accounting Date

Specify the date on which the accounting entries are posted.

Rate Pickup Date

Specify the date on which rate is picked up.

5.5.3.3 Specifying Other Details

Receiver

Indicate the name of the receiver or receiving institution that receives the message regarding the transfer of funds, if it is different from the Account with Institution.

For incoming FT contract created through STP, the receiver will be updated based on the debit account

5.5.3.4 Enriching FT Contract

In case of an outgoing FT contract, specify the credit amount and click the ‘Enrich’ button. The system displays the debit amount. Similarly, in case of an incoming FT contract, you need to specify the debit amount. The system will display the credit amount on clicking ‘Enrich’ button.

Each time you modify the transaction details such as Debit Account, Credit Account, Exchange Rate, Debit Value Date, Credit Value Date or Transaction Amount, you need to click ‘Enrich’ button before saving the modification.

Note

If you do not click ‘Enrich’ button before saving the record, the system will validate the data with the corresponding values as per the product, settlements and customer spread main­tenance. If the values specified on this screen do not match those in the maintenances, the system will overwrite the values entered by you.

5.5.4 Specifying Party Details

Click ‘Party Details’ tab to invoke the following screen.

Here you can enter the following details:

5.5.4.1 Specifying Name and Address of Ordering Customer (By Order Of)

Indicate the name and address of the ordering customer or institution of the transfer in the field ’By Order Of‘. Input into this field depends on the type of transfer that has been initiated. You can also choose the BIC of the customer from the adjoining option list that displays all the BIC maintained in Oracle FLEXCUBE. The details that you enter will be used to determine the settlement route of the transfer and in the SWIFT messages that are generated for the transfer.

This field corresponds to field 50 in the MT 103/MT 103+ message that will be generated for the customer transfer. Here you can specify up to 4 lines (each of 35 characters) indicating the ordering customer’s name and address or BIC. The details in this field will be defaulted automatically once you enter the debit account in the case of an outgoing transfer. For instance, the IBAN of the customer will be fetched from customer account and defaults the same as the first line of Ordering Customer. Note that for an outgoing MT102, MT103, MT103+ and MT210 the first line should have number 1 present for option F. The customer’s name will be defaulted in the second line and the address on the third.

Country

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

5.5.4.2 Specifying Account with Institution

Indicate the institution where the beneficiary’s account is to be credited with the amount of the funds transfer. This is known as the account with institution. This field corresponds to Field 57 of the payment message.

Country

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

5.5.4.3 Specifying Details of Ultimate Beneficiary of Transfer

Indicate the name and address of the ultimate beneficiary of the transfer. The ultimate beneficiary can be a customer or institution depending on the type of transfer that you have initiated.

For incoming or internal transfers, you can select the ultimate beneficiary from the option list. If you have maintained settlement instructions for the ultimate beneficiary the transfer will be routed through the default settlement route. This field corresponds to Field 59 of the customer transfer messages (MT 103/103+) and field 58 in case of a bank transfer. When you choose the credit account (in the case of an incoming transfer) the details of the ultimate beneficiary (like IBAN) will be defaulted automatically by the system. While saving the contract, System will Validate Ultimate beneficiary (59) for a valid IBAN account number. IBAN validation will be done in the below cases for both Ordering Customer and Ultimate beneficiary. The system will consider the IBAN valid only if:

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 analyze the transactions for pos­sible money laundering activities.

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

5.5.4.4 Capturing Remittance Information

You can specify the sender to receiver information of the transfer by selecting the appropriate value from the adjoining option list. The details that you enter will be populated in field 70 of the payment message MT 103. The following values are available in the option list:

Apart from the values provided in the list, you can also specify a valid ISO11649 creditor reference number in the Remittance Information field.

Validations

System validates the specified reference number and displays the error message, if found wrong as ‘Invalid Value for field Remittance Information’.

The Creditor Reference Number, if specified, should adhere to the following:

If Creditor Reference Number is specified in any of the remittance information fields, then during message generation the system ignores rest of the remittance information.

5.5.4.5 Specifying Beneficiary Advice Preferences

For outgoing remittances, you can indicate the mode of sending advice to beneficiary here. The details specified in Ultimate Beneficiary Maintenance get defaulted here. You can modify these values, if required.

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 ad­dress.

The system generates the beneficiary advice based on the details specified here, during contract initiation or during the batch for future dated remittances. ‘BEN_ADV’ message type is used for generating the advice. The advice generated contains the following tags:

Note

For more details on Ultimate Beneficiary maintenance, refer the section titled ‘Maintaining Ultimate Beneficiary details’ in Settlements user manual.

5.5.5 Capturing Additional Details

Capture more information with regard to the product from ‘Funds Contract Transfer Input – Other Details’ screen. From the ‘Funds Transfer Contract Input’ screen, click the tab titled ‘Additional Details’ to invoke the following screen.

5.5.5.1 Indicating Preferences

Oracle FLEXCUBE allows you to indicate your preferences. You can check the boxes corresponding to the following fields as required.

Override Overdraft

The Override Overdraft field is applicable to future dated contracts. This field is defaulted based on the specifications you made in the Process overdraft for Autobook field on the product preference screen.

The Autobook function automatically liquidates future dated funds transfer contracts. There could be a situation where a customer requests you transfer an amount that actually exceeds the balance in his account. In this field you can specify whether such future dated contracts, can be processed when it is picked up by the autobook function, despite the overdraft. If you check against this field the system will allow overdrawing and process such contracts.

Otherwise the auto book function will skip the contract with an error message. You can view all the contracts that are not processed by the Autobook function because of the overdraft in the FT Exception Report.

Remit Message

This is defaulted from the product level. If you wish to send the envelope contents, you need to check this box.

The following validations will be carried out in Oracle FLEXCUBE if the ‘Remit Message’ box is checked:

The remit message will be displayed in the message in Block 119 as 119:REMIT.

Our Correspondent Required

If the transfer is routed through a correspondent bank, you can indicate so, by selecting this option.

After Rate Refresh

To recall, you have specified the exchange rates to be used and indicated when they are to be applied to the components of the transfer. You have the option to indicate that the rates should be picked up only after the rates have been refreshed and authorized for the day.

Check against this field to indicate that the standard rate as of as of a future date can be applied to the transfer only after the rates have been refreshed and authorized for the day. Leave it unchecked to indicate otherwise.

If you have checked against this field, the exchange rate is picked up by the same method mentioned for the standard rate, except that the rate as of booking, spot or value is picked up only after the rate refresh has been completed and has been authorized.

When you run the Rate Update function, all contracts that require a rate update will be displayed. It is from this screen that you can allow the refreshed rates to be applied to the components of the transfer.

Refer to the chapter titled Automatic Processes for details of the rate update function.

Uploaded

If the contract has been uploaded from the Oracle FLEXCUBE FT gateway interface then the field marked Uploaded will be automatically checked to indicate that the contract has come from an external system. For details, refer the section ‘Specifying upload details’ in this chapter.

5.5.5.2 Specifying Check Details

Indicating the Manager’s Check number

This is the identifying number of the Manager’s check that you issue for outgoing transfers by check. This number should be unique across contracts and is used as a reference for outgoing transfers.

For transfer types involving a Manager’s Check, the beneficiary account field will be defaulted with the Manager’s Check payable account defined for the product.

Note

It is mandatory for you to enter a manager’s check number if you have checked against Instrument Number Required in the Product Preferences screen. On the other hand, you will not be allowed to make entries into this field, if the Managers check allowed field is unchecked in the FT Product Preference Screen.

Indicating a customer check number

If you are processing an outgoing transfer and need to debit a check into a customer account, you should indicate the identifying number of the check being used in the transfer.

The check number that you enter will have to match number validations in the check book details table maintained in the Current Account and Savings Account (CASA) module of Oracle FLEXCUBE.

Delivery Mode

Select the mode of delivery of the cheque book from the adjoining drop-down list. This list displays the following values:

Note

If the delivery mode is ‘Courier’, then you will need to specify the delivery address.

Delivery Address 1

Specify the address to which the cheque book should be delivered. The adjoining option list maintains all valid addresses maintained in the system. You can choose the appropriate one.

Delivery Address 2- 4

Specify the address to which the cheque book should be delivered.

5.5.5.3 Specifying Regulatory Reporting Details

Specify the regulatory reporting details.

5.5.5.4 Specifying Multi Credit Transfer Details

Enabling Multi Credit transfer

You cannot enable or disable the Multi Credit Transfer option. It is defaulted from the product/branch level and cannot be changed by you at the contract level. This option will be enabled for ‘Multi. Customer Transfer’ and ‘Multi Financial Institution Transfer’ type of payments only and will not be enabled for other normal products.

Multi Credit Reference Number

You can assign a Multi Credit Reference number to a specific contract by clicking the option list to choose from the list of Multi Credit Reference Numbers that are pending closure. During contract save, the system validates the above-mentioned fields with existing contracts and if the current transfer/transaction is identical to an existing contract it is pooled together with the existing contract and it also assumes the same ‘Consol Account Reference ’ number as the existing one. [Only Consolidation Pool pending closure, will be considered] In case the above fields are not identical or if the number of contracts in the Pool exceeds 10, the system generates a new ‘Consol Account Reference’. In case you do not specify any ‘Multi Credit Ref No’ the system would generate a ‘Consol Account Reference’ for the first time.

Note

Processed Consolidation Pools will not be considered for matching.

If grouping is done by the system, based on grouping criteria then ‘Multi Credit Ref No’ would be NULL and ‘Consol Account Reference’ would be used to consolidate accounting entries. In case you are doing the consolidation by yourself, the ‘Multi Credit Ref No’ would be the Reference Number given by you and ‘Consol Account Reference’ would be used to consolidate Accounting Entries.

All Multi Financial Institution Transfer contracts would have Messaging, Accounting and Rate as of booking date only. The ‘After Rate Refresh’ field will not be enabled for such contracts.

Amendment of Contract will be allowed only if Message has not been generated. If any of the above mentioned fields used for grouping are changed, the contract would be tracked against a different consolidation pool depending on the new values.

During the contract authorization, payment messages will be generated in suppressed stage. Message generation happens after the individual queue is closed.

If you close a Consolidation Record by means of the Close Button or the Close option from the menu, the consolidation record is liquidated. The system generates MT102, MT203 or MT201 for multi customer credit transfer, multi credit bank transfer or multi credit own account bank transfer respectively. Further, consolidated accounting entries are posted. Generation of MT102 and MT203 provides for the generation of consolidated cover messages. One cover per each MT102/MT203 is sent along with the consolidated amount.

During closure of consolidated record, the system triggers CINT (Consolidation Event for both Messaging and Accounting) event.

Consol Account Reference Number

The consol account reference number is system-generated. This number is the reference that facilitates consolidation of the various transfers of a customer, based on the grouping criteria. It facilitates passing Consolidated Accounting entry to the Beneficiary Account/Settlement Account.

The following items are checked for consolidating transfers across the system:

All transactions that have identical above-mentioned fields/items are validated and consolidation happens if intermediary party [tag 56] is not mentioned in any of the transaction.

The systems checks whether the beneficiary of the message is MT102/ MT203 enabled and also if ‘Multi Credit Transfer’ flag is enabled at the BIC level. If the field is not enabled, the system will generate an error message.

Consolidation Status

The system indicates whether the consolidated contracts for a given multi credit reference number are pending closure (P) or closed (C).

Note

The Multi transfer message is generated upon the closure of the reference number. How­ever upon the authorization of each individual contract, the corresponding payment mes­sage is in the generated status. But the status of the Suppress Flag is ‘Y’ for the same. Hence the Job which processes the outgoing message does not process these messages.

Debit Consolidation Reference Number

The system displays the contract reference number of the consol internal FT contract created for customer debit consolidation.

Message Generation

For processing outgoing MT102+, the following validations are done:

If with the above validation, you check the option ‘Generate MT102+’ in addition to ‘Multi Credit Transfer ’ in the following screen, MT102+ will be processed

Outgoing Consolidation Queue

You can generate MT 102 and MT102+ message from Queue called ‘Funds Transfer Multi Customer Summary’ where Consolidation of individual MT102s is done.

You can invoke the screen by entering ‘FTSTCONS’ in the field at the top right corner of the Application toolbar and clicking the adjoining arrow button.

In this screen, you can query on record based on the following criteria:

This Queue gives the summary of all the consolidated transactions. Drill down gives the Summary screen of the FT contract.

Close of the Consolidation Record initiated through the Close Button or Close option from the menu liquidates and creates MT102 and consolidate accounting is also passed. Events called ‘CINT’ (Consolidation Event for both Messaging and Accounting) get triggered during closure of consolidated record.

Generation of MT102 would also generate Consolidate Cover message if required with consolidated amount i.e. one cover per MT102 would be send with consolidate amount if cover is required.

MT203 size restrictions

 

5.5.5.5 Specifying Other Details

External Deal Linkage Number

Select the deal reference number of the related external deal from the option list provided. The option list contains system generated reference numbers for all external deals.

The exchange rate, Dr amount, Dr account, Dr currency, Cr amount and Cr currency get defaulted on selecting the external deal reference number.

Note

This is applicable only for outgoing remittance transactions.

Deal Reference Number

The deal reference number associated with the selected deal linkage number gets displayed here.

On initiating this transaction, the amount block maintained against this deal reference number gets released. The amount blocks associated with future dated contracts are released when the corresponding batches are run.

If the contract is deleted or reversed, the amount block gets reinstated with the expiry date as the expiry date maintained in External Deal linkage screen.

Note

For more details on external deal maintenance, refer section titled ‘External Deal Maintenance’ in Core Services user manual.

Unique End to End Transaction Reference

The system displays tag 121 value of category 1 and 2 SWIFT messages.

5.5.5.6 Specifying Envelope Details

Specify the envelope content.

5.5.5.7 Reversal of Outgoing Multi Credit Customer Transfers

In case of reversal of outgoing multi credit transfer, the system passes accounting entries based on the status of MT102 generation.

Scenario 1 - MT102 Not Generated

If MT102 is not generated, the system will pass the following accounting entries during reversal process.

Dr/Cr

Account

Description

Dr.

Remitter

With –ve Transaction Amount

Cr.

MT102 Sus­pense

With –ve Transaction Amount

Once these entries are passed, the system will adjust the total consolidated amount and remove the corresponding contract from the consolidation queue.

Scenario 2 - MT102 Already Generated

If MT102 is already generated, during reversal, the system will display an override ‘Message has already been generated’. If you choose ‘OK’, the system will proceed with the reversal operation. The following accounting entries will be passed in this case.

Dr/Cr

Account

Description

Dr.

Remitter

With –ve Transaction Amount

Cr.

MT102 Sus­pense

With –ve Transaction Amount

Dr/Cr

Account

Description

Dr.

MT102 Sus­pense

With –ve Transaction Amount

Cr.

Cr. Beneficiary

With –ve Transaction Amount

On reversal of an individual transaction, the corresponding CINT event will also be reversed. The system will recalculate the consolidation pool amount.

Closure of consolidation pool is allowed for authorized transactions only. If you attempt to close an unauthorized transaction, the system will display an error message.

While marking EOTI, if there are pending consolidated transactions in MT102 consolidation queue, the system will display a configurable override message. You can choose to proceed or cancel.

5.5.5.8 Indicating when Settlement Messages should be Generated

Indicate the day or date on which Settlement messages related to the transfer should be generated. You can select an appropriate date from the option list that is available.

The options available are:

If the transfer you are processing is associated with a product, the message generation specifications you made for the product is defaulted. You can change the values that are defaulted if required.

Message as of Booking Date

If you specify ‘Booking Date’, settlement messages will be generated as of the date you enter the contract after the contract is authorized.

Message as of Spot Date

For each currency that your bank deals with, you would have also specified a spot date in the Currency Definition Maintenance table of the Core Services module.

If you choose ‘Spot Date’, messages will be generated spot days depending on the spot date you have maintained for the currency involved in the transfer.

Message as of Value Date

If you specify value date, messages will be generated on the day the transfer becomes effective.

You can enter a value date of your choice. However, it should be one of the following:

You can enter a date in the future only if future value dating is allowed for the product to which the transfer is associated. The Value Date (transfer initiation date) should not be earlier than the Start Date or later than the End Date of the product involved in the transfer.

Message as of Debit Value Date

If you choose this option, the messages will be generated, as on the value date, with which the remitter account will be debited, will be used for the transfer. This would be earlier than the credit value date.

Message as of Credit Value Date

If you choose this option, the messages will be generated on the value date with which the beneficiary account will be credited, will be used for the transfer. The credit value date is in reality the value date (transaction date) of the transfer.

Messages can be generated only after the exchange rate for the contract has been fixed. Thus, based on the rate pick up code that you specify, you will have to match the options for message generation.

For normal contracts (as of booking date) messages will be generated only after authorization. In the case of Future Valued transfers messages will be generated as of spot date.

Message Date

This is the actual date on which the messages are to be generated. This date is computed on the basis of the input in the ‘Message as of Field’ in the ‘Contract – Others’ screen.

5.5.5.9 Specifying when Accounting Entries must be passed

For the contract, you can specify whether accounting entries must be passed on the date of message generation (if message generation is indicated on booking date) or on the debit value date of the transaction.

If you indicate that accounting entries must be passed on the date of message generation, the entries related to the contract will be passed on the date of message generation. If message generation is indicated on booking date, and you have indicated that accounting entries are to be posted on the debit value date of the transaction, the messages are generated on the booking date, and the accounting is deferred to the debit value date.

The accounting date

When you make your specification in the Accounting As Of field, the system arrives at the date on which accounting entries will be posted, and displays it in the Accounting Date field on the FT Contract Online screen. If you select ‘Message Date’, the date on which messages are generated is taken as the accounting date. If you select ‘Debit Value Date’, the debit value date of the transaction is taken as the accounting date.

You can only specify the Accounting As Of date if:

For the messages as of specific dates, you can choose accounting as of specific dates as listed in the table below.

Message as of

Accounting as of

Booking Date

Message Date or Debit Value Date

Value Date

Message Date

Spot Date

Message Date

Debit Value Date

Message Date

Credit Value Date

Message Date

Instruction Date

Message Date

If the parameter ‘SGEN_PARAM’ in CSTB_PARAM is set as ‘Y’, the process will be as discussed below.

Message as of’’ is set to ‘Booking Date’. Suppose that ‘Accounting as of’ is chosen as ‘Debit Value Date’.

The system will trigger ‘BOOK’ event on the booking date of the contract.

On authorization of the FT contract, the system will trigger SGEN event and generate settlement messages linked to INIT event or LIQD event. For a contract, if you have checked the option ‘After Rate Refresh’, this happens during End of Day operations. INIT and LIQD events are triggered based on the Debit Value Date. For these events, the system will not generate settlement messages.

5.5.5.10 Indicating Date on which Rates should be picked up

You need to specify the date as of when exchange rates should be picked up and applied to the components of a transfer.

If the transfer you are processing is associated to a product, the preferences you stated for the product will be defaulted. You can change the values that are defaulted.

In the case of a contract that is liquidated as of the booking date, the rates will also be picked up as of the booking date.

For future valued transfers, you can specify the rate pick up date as of booking date, value date or spot date. You can select one of the following options:

Rate as of Booking Date

If you specify that the rates should be picked up as of the ‘Booking Date’, the exchange rates prevailing as of the date you enter the contract is used to compute the components of the transfer.

The spread that you specify for the transfer will be applied to the exchange rates that are picked up.

Rate as of Spot Date

Specify that exchange rates can be picked up as of spot days only for future dated funds transfers.

To recall, for each currency that your bank deals with, you have also specified a spot date in the Currency Definition Maintenance table of the Core Services module.

The spread that you specify for the transfer will be applied to the exchange rates to compute the components of the transfer.

We shall examine an example wherein the ‘rate as of’ is specified as Spot Date:

A customer of your bank approaches you on 1 March 1998 (the booking date) to initiate a cross currency transfer for US $ 10,000. Assume the offset currency of the transfer to be INR. Also assume that you had maintained the spot days for USD to be 2 days in the Currency Definition table of the core services module.

The transfer is to be initiated on 5, March, 1998 (the Value Date). It is therefore a future dated transfer.

Booking Date - 01/03/96

Value Date - 05/03/96

Contract Currency - USD

Contract Amount - 1000 $

Spot Days maintained for USD -2

In this case the exchange rates to be applied to the transfer will be picked up from the currency table on 3, March, 1997, Spot days (2 days) before the Value date of the transfer.

Rate as of Value Date

If you specify ‘Value date’ then the rates to be used to process the transfer amount will be picked up on the day the transfer is effected. The accounting entries for the contract will be passed as of this date.

Enter a value date of your choice. In which case, it should be one of the following:

The Value Date (transfer initiation date) should not be earlier than the Start Date or later than the End Date of the product involved in the transfer.

Indicating that exchange rates will be ‘User Input’

If you do not want to make the standard exchange rates applicable to a transfer you can choose ‘User Input’ from the option list.

In this case, the exchange rate that you enter in the exchange rate field of the Contract Main screen is picked up to compute the components of the transfer.

Indicating that exchange rates are not applicable

If you are processing a transfer wherein the currency that is remitted is the same, as the currency that is credited, you can indicate that exchange rates are not applicable to the transfer.

Rate as of Instruction Date

If you chose this option, the rate as of the date on which the customer placed his instruction will be taken. This is similar to booking date.

Rate as of Debit Value Date

If you choose this option, the exchange rate as on the value date with which the remitter account will be debited, will be used for the transfer. This may be earlier than the credit value date.

Rate as of Credit Value Date

If you choose this option, the exchange rate as on the value date with which the beneficiary account will be credited, will be used for the transfer.

Rate Pickup Date

This is the actual date on which the rate is picked up. This date is computed based on the input given in the ‘Rate as of’ field on the ‘Contract Other’ screen.

Social Security Number

If you are processing a funds transfer on behalf of a customer of your bank, the Social Security Number of the customer involved in the transaction will be defaulted from the CIF Maintenance details screen. However, if you are initiating the funds transfer for a walk-in customer you will have to capture the walk-in customer’s SS Number.

Note

Each outgoing customer type of transfer initiated by an individual type of customer can be tracked against the customer’s SS number. If the value of debits within a specific customer account exceeds USD 2500, with-in a seven-day working period the system notifies you of the same with an override message.

For example,

Let us assume that on the 24th of September 2001, Mrs. Wendy Klien a customer of your bank initiates an outgoing FT for USD 2000. Since all weekends are considered as holidays at your bank, while processing the transfer all debits against her account for six working days preceding the 24th i.e., up to the 16th September will be tracked against her SS number.

Again, on the 1st of October 2001, she initiates another outgoing transfer, which necessitates a deduction of USD 700 on her account. While processing the transfer the system checks for all debits up to the 21st of September.

An amount of USD 2000 has already been tracked against her SS number on the 24th of September. However, since the current debit exceeds the maximum limit of USD 2500 for a running seven-day working period the transfer will be processed only if your confirm the override.

5.5.6 Note on Rate Pickup and Message Generation

The Rate pickup and message generation codes that you specify for a transfer need to be combined in a fashion to facilitate the following flow of events:

  1. Rate pickup
  2. Message Generation

Accounting entries will be passed and then messages will be generated. All the possible combinations between the rate pickup and the message generation codes have been explored and detailed below.

Note

If message generation has been indicated to occur before accounting is done for a con­tract, the accounting entries are posted on the Accounting As Of date. This could be either the date of message generation or the debit value date of the transaction, as explained in the earlier section.

Standard rate as of booking date - Message as of Spot Date

If you select this combination:

Rate as of Spot - Message as of Spot

If you choose this combination:

Rate and Message as of Value Date

If you choose this combination the transfer amount will be converted based on;

Rate as of Booking Date - Message as of Booking Date

If you select this combination, the system converts the transfer and commission amount based on the:

Rate as of Spot Date - Message as of Booking Date

In this example the rate date is later than the message date and hence this would not be allowed by the system. The message generation in Oracle FLEXCUBE happens along with the accounting and therefore, the rate pick-up date must be on or before the message generation date.

5.5.7 Limit Amounts for Cross Currency Transactions for Default of Exchange Rates

Typically, the exchange rates applicable for cross currency funds transfer transactions is defaulted by the system depending upon the preference indicated in the product preferences, for the product involving the transaction.

In your bank, for high-value cross currency transactions, you may want the user to manually enter the exchange rate involved, rather than let the system automatically pick up a default rate during transaction input. You can define such a preference to be applicable to cross currency transactions involving:

The transaction amount limit, above which the exchange rate must be entered, for a high value transaction, could be defined in terms of any currency pair where the currency of the transaction is currency1 in the CCY pair defined in the maintenance.

To ensure that users manually enter exchange rates for high-value cross currency transactions in Oracle FLEXCUBE, you must specify the limit amounts that must be validated against for each currency pair, product, module and branch combination. You can use the Exchange Rate Limits screen to specify the limits.

When you have specified these limits, the system automatically validates the amount each transaction for the currency pair, product, module and branch combination, and accordingly, if the limits are exceeded, enforces the manual entry of exchange rates.

In case, the limit between ccy1 and ccy2 is given in ccy2, the system will automatically convert the transaction amount to an amount in ccy 2 using standard mid rate and check against the limit amount for manual entry of exchange rates.

5.5.8 How Limits are applied when Transaction is Entered

Whenever a cross currency funds transfer or teller transaction is entered, Oracle FLEXCUBE checks for appropriate limits, in the Exchange Rate Limits Maintenance. If no limits are maintained for the currency, product, module and branch combination, then no limits are applied.

The example given below illustrates how the system identifies the appropriate limit from the Exchange Rate Limit Maintenance.

For example,

You have maintained the following amount limits for cross currency teller and funds transfer transactions in your bank, in the Exchange Rate Limit Maintenance:

Number

Branch

Module

Product

currency1

Currency 2

Limit Ccy

Rate Type

Limit amount

1

001

DE

PRD1

USD

GBP

GBP

Stand­ard

25000

2

001

FT

PRD2

USD

INR

USD

Spot

40000

3

ALL

FT

PRD3

GBP

USD

GBP

For­ward

20000

For each transaction, the corresponding limit amount to be validated against is derived by checking if a limit has been maintained for the following combination of parameters in sequence:

For instance, for a teller transaction involving USD-GBP and product PRD1 in branch 001, the limit amount that will be used for validation is 25000 GBP (corresponding to Number 1 in the table above).

For a funds transfer transaction involving any currency pair and product PRD3, in any branch, the limit applicable would be 20000 GBP (corresponding to Number 3 in the table)

5.5.9 Exchange Rate for Cross Currency Transactions

After the limit applicable for a cross currency transaction has been identified, it is validated in the following manner:

  1. The limit amount, which is expressed in the limit currency, is converted to the corresponding amount in currency1, using the standard exchange rate, mid rate for comparison.
  2. If the transaction amount falls below the limit amount in currency1, the limit has not been exceeded. In such a case, the exchange rate for the transaction is picked up from the Currency Rates Maintenance for the rate code specified in the preferences of the product involving the transaction, and is defaulted to the transaction.
  3. If the transaction amount exceeds the limit amount in currency1, the exchange rate for the transaction is not picked up according to the rate code defined in the product preferences, but will have to be specified by the user entering the transaction. The specified rate is checked to verify that it falls within the variance limits and the stop limit specified for the product.

5.5.10 Internal Remarks

You can specify additional information pertaining to the contract here. The details that you specify here can be retrieved later.

5.5.11 Capturing Payment Details

Specify the sender to receiver information of the transfer by selecting the appropriate value from the adjoining option list. The details that you enter will be populated in field 72 of the payment message MT 103.

The following values are available in the option list:

5.5.12 Specifying Upload Details

If the contract has been uploaded from the Oracle FLEXCUBE FT contract upload tables by the FT Upload function then the field marked Uploaded will be automatically checked to indicate that the contract has come from an external system. The code of the source from which the contract was uploaded will be displayed in the Source Code field. Each time contracts are uploaded, the system automatically generates a source reference number. This number will be displayed in the Source Ref Number field.

(Refer to Chapter titled The Batch Upload Function for details on the FT Upload function)

Storing the External System Generated Reference Number

Oracle FLEXCUBE interfaces with the MUREX system, uploading and processing funds transfer contracts from MUREX. A contract uploaded from MUREX can result in one or more contracts in Oracle FLEXCUBE. Therefore, in order to relate the Oracle FLEXCUBE contracts with the corresponding MUREX system generated contract, the source (MUREX) reference number will be stored in field 21 of MT 900 (Dr Advice) and MT 910 (Cr Advice) for handoff to customers.

Note

This feature is only available for contracts uploaded from the MUREX system.

MT940 (detailed account statement) and MT950 (summary statement) will also store the source reference number in field 61 (sub-field 8) for handoff to customers.

5.6 Viewing Settlement Route of Transfer

After entering the details of a transfer click the tab titled Settlement Route from the contract details screen. A screen depicting the route that you have defined for the transfer is displayed. This facility provides you a quick means of verifying the transfer route. If the route of the transfer is incorrect, you can delete or change the contract suitably.

Based on the type of transfer that you have initiated and on the settlement details that you specify for the transfer, the fields of this screen will be populated. We shall explore all the possible routes that a transfer can take before it reaches the ultimate beneficiary.

Ordering Customer - The name of the ordering customer (the party that has initiated the transfer). This field will be populated only if you have initiated a customer transfer (MT103/103+).

Ourselves - The financial institution or the branch, thereof, initiating the transaction on behalf of itself or its customer.

Our Correspondent - The name of the correspondent bank if the transfer is routed through a correspondent.

Receiver’s Correspondent - The institution that will receive funds on behalf of the receiver is displayed. Hence this field will be populated only for outgoing transfers.

Intermediary Reimbursement Institute – The financial institution between the Sender’s Correspondent and the Receiver’s correspondent, through which the reimbursement of the transfer will take place.

Intermediary - The intermediary between the receiver and the account with institution.

Account With Institution - The Financial Institution at which the Ordering Party requests the Beneficiary to be paid. This field will not be populated for incoming and internal transfers.

Receiver - This is the receiver of the message.

Ultimate Beneficiary - The Ultimate Beneficiary that you specified in the Contract Main screen is defaulted.

If there is one bank between the remitter and the beneficiary then it is a one party transfer. In such a transfer, funds move directly from the bank of the remitter to the bank of the beneficiary.

If a correspondent bank is used to transfer funds form the bank of the remitter to the bank of the beneficiary then it a two party transfer and so on. This has been illustrated diagrammatically,

The number of banks that are involved in the transfer would depend on the:

5.6.1 FT Fields and Information Flow

The fields in the FT input screen that decides the direction and flow of funds and messages are:

The following examples illustrate how information flows in various conditions.

An Example of a one party transfer

Girozentrale Uno Bank, Vienna, receives a letter from Wonderdrug Pharmaceuticals ordering them to pay US $ 40,000 to the National Bank, New York into the account of Silas Reed.

At Girozentrale Uno Bank, the settlement screen will be populated with the following details:

Field name on the Settlement Screen

Entry

Ordering Customer

Wonderdrug Pharmaceuti­cals

Ourselves

Girozentrale Uno Bank.

Receiver

National Bank, New York.

Ultimate Beneficiary

Mr. Silas Reed.

 

An Example of a two party transfer

Vanbee Traders orders Banca Commerciale, Naples to pay, value 27 May 1997, and 120,000 Francs into the account of Mr. Silas Reed with Banque Nationale de Paris, Grenoble. Banca Commerciale asks LeanderBank to make the payment which in turn pays through Banque Nationale de Paris, Paris branch.

At LeanderBank the settlement screen will be populated with the following details:

Field name on the Settlement Screen

Entry

Ordering Customer

Vanbee Traders.

Ourselves

Banca Commerciale, Naples.

Our Correspondent

LeanderBank.

Receivers Correspondent

Banque Nationale de Paris, Paris.

Receiver

Banque Nationale de Paris, Grenoble.

Ultimate Beneficiary

Silas Reed.

 

An Example of a three party transfer

On May 10, 1997, Wendy Klien orders Leander bank Vienna to pay US dollars 20,000 to Silas Reed, whose account is with Algemene Bank Nederland (ABN), Amsterdam. The beneficiary is to be notified by phone. A cover message for the US Dollar payment is provided through Hansen Trust Company, New York to ABN New York.

At Leander the settlement screen will be populated with the following details:

Field name on the Settlement Screen

Entry

Ordering Customer

Wendy Klien

Ourselves

Leander Bank, Vienna

Our Correspondent

Hansen Trust, New York.

Receivers Correspondent

ABN, New York

Receiver

ABN, Amsterdam

Ultimate Beneficiary

Silas Reed.

An Example of a four party transfer:

G.A. Imports Naples orders Banca Italiana Milan to pay USD 500000 to BNP bank, Normady to the account of Silas Reed. Banca Italiana Milan makes the USD payment through its US Correspondent, Banca Italiana, New York. Payment is made to BNP Paris in favor of BNP Normandy through its US correspondent Bank of New York, NY.

At Banca Italiana, Milan the settlement screen will be populated with the following details:

Field name on the Settlement Screen

Entry

Ordering Customer

G.A Imports.

Ourselves

Banca Italiana, Milan.

Our Correspondent

Banca Italiana, NY.

Receivers Correspondent

Bank of New York, NY.

Receiver

BNP, Normandy.

Ultimate Beneficiary

Silas Reed.

 

5.7 Viewing Details of Transfer Events

Click ‘Events’ button in the 'FT Contract Detailed View screen to go to the FT Contract View Events screen. In the FT contract view events screen the list of events that have already taken place on a contract along with details of pending events is displayed. The date on which the event took place will also be displayed.

Click ‘Account Entries’ button to view the accounting entries for the event. Click ‘Exit’ button to go back to the FT Contract Detailed View screen.

5.7.1 Viewing Accounting Entries that are Passed

From FT Contract — View Events screen, click ‘Accounting Entries’ to view the Accounting Entries for the event. You can view the details of the accounting entries that were passed for the event whose details were displayed in the contract -- View Events screen. The accounting entries that are passed depend on the type of transfer that you initiate. The following information is provided for each event:

All the overrides that were allowed for an event will also be displayed.

5.8 Specifying Advices for Transfer

From the ‘Funds Transfer Contract Input’ screen, click ‘Advices’ button to view the ‘Advices’ screen is displayed. In this screen you can specify the advices that are to be generated for the various events that occur during the lifecycle of a funds transfer, after the authorization of the product.

Suppressing the generation of an advice

By default all the advices defined for the product to which the FT is associated will be applicable to the FT.

As all the messages defaulted from the product may not be applicable to the contract you are processing, you can suppress their generation.

Select a value from the adjoining drop-down list to the relevant message. This list displays the following values:

Indicating the priority with which a message should be sent

Specify the priority with which an advice should be generated. By default the priority of all advices is marked as ‘Normal’. You can prioritize advices into one of the following:

Note

After you have selected the advices to be generated for the contract, click ‘Ok’ button to save it. Click ‘Exit’ button to exit the screen without saving the entries. In either case, you will return to the FT Contract Main screen.

5.9 Selecting User Defined Fields

Click ‘Fields’ button from the ‘Contract Main’ screen to invoke the ‘User Defined Fields’ screen. The list of fields and default values specified for the product to which the transaction is associated is displayed.

Add to the list of fields defaulted from the product but you will not be allowed to remove a field from the defaulted list.

Change the values defaulted from the product to suit the transaction you are processing.

5.10 Generating Charge Claim Advice

For incoming FTs, the remitter bears the charges if the option ‘Charge’ is set as ‘Ours’. For such contracts, you can direct the remitter to pay the defined charge amount by generating a Charge Claim Advice (MT191). Click ‘Charge Claim’ button from the Funds Transfer Main screen to specify details for the generation of the message MT191.

Contract Reference Number

The system displays the reference number of the contract in this field.

Event Sequence Number

The system displays the event sequence number. This indicates a number corresponding to the number of events for which the operation has been performed.

Specifying a Charge Reference Number

Enter a reference number to identify the message. The identification should ideally indicate the incoming FT for which it was generated. The User Reference of the FT is defaulted. You can change the reference that is defaulted. The charge reference number will be displayed in field 21 of the charge claim advice.

Indicating the Charge amount and currency

Enter the consolidated charge amount that is to be claimed for the FT. The charge amount is expressed in the charge currency that you specify. If all the charge components are in the same currency, the system automatically calculates the charge amount in the charge currency.

If the FT involves several charge components, in different currencies, you should consolidate them and express the charge amount in the collection currency.

Charge Details

The details that you enter in this field are printed on the SWIFT message. Therefore the details that you enter here should conform to SWIFT standards. In this field you can enter specifications of the charges, interest, or other expense(s) associated with the transfer. An MT 191 can contain one or more of the following codes, followed, where relevant, by the currency and amount:

Sender to Receiver Information

Here you can enter a message that the sender would like to send to the receiver of the message.

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 S.W.I.F.T. You can enter one of the following:

Ordering Institution

Indicate the ordering institution of the original incoming FT. 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 S.W.I.F.T.

In this field you can enter one of the following:

5.11 Specifying Customer Cover Details

You can specify the cover details associated with the customer involved in the transfer in ‘Customer Transfer Details’ screen. To invoke this screen, click ‘Customer Cover Details’ button in ‘Funds Transfer Contract Input’ screen. For STP transfers these details are automatically defaulted from the party details captured.

You can input details here only for if the contract is being booked using the product having transfer type as ‘Customer Transfer with Cover’. (STP Failure cases).

You can specify the following details in this screen:

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 STP has failed or while manually booking the FT contract using the incoming 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 the:

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:

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:

Ultimate Beneficiary Details

The Ultimate Beneficiary refers to the customer to whom the amount of the component is to be paid. This field refers to field 59A of SWIFT. You can make entries into this field only if STP has failed or while manually booking the FT contract using the incoming SWIFT message. This would not be applicable for Bank Transfers.

Specify the identification, name and address details of the ultimate beneficiary involved in the transaction.

Sender to Receiver Information

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

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

Remittance Information

Specify the payment details of the FT contract here.

This field corresponds to field 70 of the SWIFT message. This will be populated only for RTGS related messages.

External reference number

Specify the reference number of the customer transfer, received from the originating bank.

This field corresponds to field 21 of the SWIFT message. This is the reference number (Field 21) of the incoming message received.

Currency

Specify the currency associated with the customer transfer.

Amount

Specify the amount associated with the customer transfer.

5.12 Viewing OFAC Check Response

OFAC check enables the application to call an external web service to perform black list check for customer and customer accounts and give warnings appropriately while transacting with black listed customers. You can also capture your remarks before overriding the black list warning.

Click ‘OFAC Check’ button in ‘Funds Transfer Contract Input ‘Customer Account Creation’ screen to view the OFAC check response in the ‘External System Detail’ screen On clicking ’OFAC Check’ button, system will build the request XML and call the web service. The ‘External System details’ screen displays the response is received from the external system and you will be also allowed to enter your remarks in this screen. The response received will also be sent to Oracle FLEXCUBE Database layer for any further interpretations of the same.

This button can be made visible while carrying out the actual customization. Request building response interpretation in the database layer needs to be done as part of customization to enable this.

Here, you can view /capture the following details:

External System Response

The response from the external system regarding the black listed customer is displayed here.

User Remarks

Specify your remarks regarding the black listed customer here.

5.13 Capturing MIS Details

5.14 Viewing Change Log

 

5.15 Specifying Settlement Details

You can capture the settlement details associated with a transfer in ‘Settlement Details’ screen. Click ‘Settlement’ button in ‘Funds Transfer Contract Input ‘screen to invoke the ‘Settlement Details’ screen.

 

The FT transaction is settled based on the details specified in this screen.

For more details on this screen, refer the section titled ‘Processing Settlements’ in Settlements User Manual.

5.16 Viewing All Messages

You can view a list of all the messages generated for a particular FT contract using ‘View Messages’ screen. Click ‘All Messages’ button on ‘Funds Transfer Contract Input’ screen. You can invoke the screen by typing ‘MSDALMSG’ n the field at the top right corner of the Application tool bar and clicking the adjoining arrow button

Contract Reference Number

The system displays the reference number of the contract.

Message

The system displays a list of all messages generated for the above contract. The list contains the following details of each contract:

Message Type

The system displays the message type.

SWIFT Message Type

The system displays the list of SWIFT Message Type.

Sub Message Type

This field displays the type of sub message type.

SWIFT Sub Message Type

The system displays SWIFT Sub message type.

From this screen, you can view the details of a particular message. Use the adjoining checkbox to select a message and click ‘Message’ button. The system displays the details of the selected message on a separate window.

5.17 Specifying Project Details

Click the ‘Project Details’ button in the ‘Funds Transfer Contract Input’ screen and invoke the ‘Project Details’ screen. You will have to capture project details in this screen only if the credit account is a Trust account.

Specify the following details:

Project Name

Specify the developer project name for which payment is being made. The adjoining option list displays all valid projects maintained in the system. You can select the appropriate one. Input to this field is mandatory.

If you specify the Unit ID, the system will display the corresponding project name here.

Unit Payment

Indicate whether the transaction is a unit payment or not by choosing the appropriate value from the adjoining drop-down list. The following values are available:

Unit ID

Specify the unit ID of the project. This field will be enabled only if you have selected ‘Yes’ against ‘Unit Payment’. The adjoining option list displays all unit IDs along with the unit holder names corresponding to the project name chosen. You can select the appropriate one.

Transfer Request Number

Specify the transfer request number for the payment.

5.18 Viewing Duplication details

The system checks for duplicate transactions while booking contracts based on the number of days for duplicate check maintained at the ‘Branch Parameters Maintenance’ screen and the duplication preferences set at the product level. The system displays the duplicate contract reference number if there is a single match else it displays the override message as ‘Duplicate Contracts recognized based on the product preference’

You can view all the duplicate contracts in the ‘Duplication Details’ screen. Click ‘Duplication Details’ button in the ‘Fund Transfer Contract Input’ screen to invoke this screen.

Here you can view the following details:

Note

Duplication check is done based on the following criteria:

5.19 Generation of MT 210 for Funds Transfer Contract

If a nostro account is being debited during the posting of accounting entries in a funds transfer contract, a Notice to Receive message (MT 210) is generated by default, if this preference is indicated in the nostro account profile, in the Customer Account Maintenance screen.

If applicable, the MT 210 message will be generated whenever the nostro account is debited, except in the following circumstances:

When you enter a funds transfer contract, with the nostro account as the debit account, the MT 210 specification made for the account is defaulted to the contract. You can change this specification when you are entering the contract. If you do so, the specification made when you enter the contract is considered instead of the specification at the account level. Also, an override is sought if you make any changes to this preference, which must be confirmed when the authorizer of the contract verifies the contract.

You can view this information in the Settlements Screen, in the Payment Message Generation checkbox field.

5.20 Generation of MT900 and 910

Oracle FLEXCUBE generates the confirmation SWIFT messages MT900 and MT910 to be sent to owners of accounts that have been debited or credited due to any transaction. The MT900 is a debit confirmation message, and the MT910, a credit confirmation message. The necessary information in each field of the SWIFT messages is picked up from the contract settlement field information. The SWIFT address of the customer is used for the generation of the debit or credit advices.

Whenever the system receives MT910, the message is verified against field 21 to match whether it can be taken as a cover message for a payment message. In case the system finds a match, the message is taken as a cover message and the payment message is processed. In case a match is not found, the system marks the MT910 for repair.

5.21 Checks for Generation of MT103+ Messages

Upon authorization of an outgoing FT contract, Oracle FLEXCUBE generates the applicable MT103 message in the MT103+ format, if the MT103+ option has been enabled as follows:

The MT103 payment message is generated in MT103+ format if:

If MT 103+ has not been enforced for the branch, currency and BIC code, the MT103 payment message is generated in the original MT103 format, that is, without the code ‘STP’ in field 119 in the third block of the message.

If MT 103+ has not been enforced for the product, an override is sought, and the message is displayed as ‘'103P format not enforced for the product. Do you still want to generate message in 103p?’

If you confirm the override by clicking OK, the MT 103 message is generated in MT 103+ format. If you reject the override by clicking Cancel, the MT 103 message is generated in the original MT 103 format.

Checks for MT103+ format

The following checks are performed by the system for the generation of MT 103 messages in the MT 103+ format:

In addition to these checks, for outgoing MT103/ MT103+ messages being generated in response to incoming MT103/MT103+ messages, the fields 33B (Currency/Original Ordered Amount) and 36 (Exchange Rate) should have been unchanged through the transaction chain. When such contracts are being uploaded or entered, the instructed amount, instructed currency, and exchange rate are picked up from the contract settlement details during outgoing MT103/MT103+ message generation, and populated in fields 33B and 36.

The following tags in MT 103 message will support a clearing code ‘PL’:

MT 103+ message type will support 52A, 56A and 57A tags:

The details of these messages will be stored in data store and will be used during message validation.

Generation of RTGS Messages

For FIN Y-Copy messages, the system validates whether it is a payment message alone or payment + cover message. If it is a payment message, then the system will generate it as a FIN Y-copy payment message. If it is a payment + cover message, then the cover message alone will be generated as a FIN Y-copy message.

The following message generation logic will be used for FIN Y-copy messages:

Following are the message types for RTGS:

Message

Description

SWIFT Message

CUST_TS­FR_RTGS

Used when a Pay message generation is for a cor­porate and sent through the RTGS Network.

MT103

BANK_TS­FR_RTGS

Used when a message belongs to an interbank deal and sent through the RTGS Network.

MT202

DIRDR_RTGS

Used when a direct debit message is sent through the RTGS Network.

MT204

COVER_RTGS

Used when a cover payment is sent through the RTGS Network.

MT202

 

Checks for Generation of MT201 Messages

There should not be multiple account relationship with the AWI in the currency of transfer.

The following are the consolidation criteria’s while generating MT201 messages:

5.22 Currency Cut-off Checks for Funds Transfer Transac­tion

If currency cut-off checks are applicable for the transaction, as specified in the preferences for the product that the transaction involves, they will be performed when you save the transaction.

The value date of the transaction is validated against the cut-off days and cut-off time specified for the product, currency and customer involved in the transaction.

The checks are applied as follows:

  1. Oracle FLEXCUBE checks to see if cut-off parameters have been maintained in the Value Dated Spread maintenance for the customer involved in the transaction, the product for the transaction and the currency of the transaction. If so, the parameters maintained for the combination are applied to the transaction.
  2. If no cut-off parameters have been maintained in the Value Dated Spread maintenance for the specific customer, product and currency combination, Oracle FLEXCUBE checks to see if cut-off parameters have been maintained for the product and currency, for all customers. If so, the parameters maintained for the combination are applied to the transaction.
  3. If no cut-off parameters have been maintained either for the specific customer or all customers, for the product and currency combination, the cut-off parameters maintained in the Currency Definition for the currency involved in the transaction are applied.

If a transaction fails any of the currency cut-off checks, the system displays a warning message informing you of the same.

You can then adopt either of the following courses of action:

If you force the transaction without changing the value date, an override is given at authorization, to the user that authorizes the transaction. If the override has been configured to be an error, the transaction would be rejected, and an appropriate reason for rejection would be sought from the authorizer. If the override has been configured to be a warning message, the authorizer can authorize the transaction.

If you choose to change the value date, the currency cut-off checks will be performed again, based on the new value date.

5.22.1 Exceptions for Currency Cut-off Checks

The currency cut-off checks, if applicable according to the product preferences, are performed for all transactions involving the product, and the currency, except in the following circumstances:

Value Date = Oracle FLEXCUBE Application Date + Transfer Currency Spot Days.

If the Currency Cut off Time is exceeded, then, the Value date is arrived at, will be incremented by one working day.

The system marks the status of all such future valued transactions as ‘pending release’, and defers the currency cut-off checks in respect of them. The checks will subsequently be performed on the value date.

Future valued transactions can be invoked, authorized and force-released by a user with appropriate rights, other than the one that entered it into the system.

5.23 Funds Transfers with Blacklisted BIC Codes

This section contains the following topics:

5.23.1 Funds Transfer Transactions with Blacklisted BIC Codes

If a SWIFT BIC Code identifying a bank or a financial institution has been blacklisted (as specified in the BIC Code Details), an override is sought when a funds transfer transaction is entered which involves any of these blacklisted codes in the party information.

The system checks for blacklisted codes when you specify any of the following parties in a funds transfer settlement:

If you specify a blacklisted BIC code in the party information, you will be prompted for an override:

5.23.2 Authorizing Funds Transfer Transaction with Blacklisted BIC Codes

If a blacklisted code has been specified for a transaction, the authorizer of the transaction can view the same at the time of authorization. All the blacklisted codes specified for the transaction are displayed to the authorizer as part of the transaction details.

At this stage, the authorizer can choose to proceed with the authorization despite the blacklisted codes. If so, an override is sought from the authorizer, and the authorization can only proceed if the sensitivity of the override is configured as ‘Warning’. If the override is configured as an ‘Error’, the authorizer cannot authorize the transaction.

5.23.3 Processing Uploaded Payment Transactions with Blacklisted BIC Codes

At the time of uploading payment transactions through the upload gateway tables, if the STP process encounters transactions involving SWIFT BIC codes (in the fields containing party information) that have been blocked, the system will display an error message.

The STP will check for blocked BIC codes in following fields of a payment transaction that is being uploaded:

If the STP process detects a blocked BIC code in any of the above party details, you will be prompted with an override:

5.24 Operations that you can perform on contracts

You can perform the following operations on a contract:

Refer to the User Manual on Common Procedures, as well as the section ‘Verifying and authorizing a funds transfer transaction’, later in this chapter, for details of these operations.

Function

When it is Allowed

Result

Reverse

After authorization

All accounting entries will be deleted. No advices will be generated.

Amend

Only for contracts for which no entries or messages have been passed (future val­ued)

 

Delete

Before authorization

Accounting entries will be deleted. Messages have not yet been generated so no action is required.

Hold

Before first save; typically done when incomplete details of a contract are filled up and the contract must not be pro­cessed.

Contract will be put on HOLD status and will not be pro­cessed by any Oracle Flex­cube process including EOD processes.

Liqui­date

When the contract is in active status (and LIQD event is yet to be triggered); for instance, the second stage of an Incoming FT where funds from DAO GL have to be made available to the Beneficiary Cus­tomer

The LIQD event gets trig­gered and the contract becomes ‘LIQUIDATED’

5.25 View Different Versions of Contract

When you enter a contract, it is allotted the version number 1. From then on each amendment results in the next version of the contract being created. When you come to the Detailed View screen of a contract, the latest version will be displayed. To navigate between the various versions use the arrows to move to the previous version and to the next version.

This section contains the following topics:

5.25.1 Verifying and Authorizing Funds Transfer Transaction

Every funds transfer transaction that you enter manually must be verified and authorized. Only a user who has appropriate rights can perform the verification and authorization functions. Such a user is called an authorizer.

You can invoke the ‘Funds Transfer Contract Authorization’ screen by typing ‘FTDTRAUT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Before a transaction is authorized, it must be verified. Verification is the process of checking the details of the transaction and ensuring their correctness. If any of the details are incorrect, the transaction could either be amended or rejected by the authorizer. After verification, the transaction can be authorized, or rejected, as is deemed necessary.

You can use the FT Contract Authorization screen to verify and authorize a funds transfer contract that has been entered manually through the FT Contract Online screen.

5.25.2 Viewing Transaction to be Authorized

To verify a transaction, you must first display its details in the FT Contract Authorization screen. To do so, you must:

  1. Select the Contract Reference Number assigned to the contract by Oracle FLEXCUBE, in the Contract Ref No field
  2. Specify the appropriate values for the rekey fields designated in the preferences for the product that the transaction involves

If you key in an incorrect value for any of the rekey fields, you cannot proceed with the verification and authorization process. You will not be able to navigate out of the rekey field for which you specified an incorrect value.

When you have specified the correct values for the rekey fields, the transaction details are displayed in the Contract Authorization screen.

5.25.3 Specifying Details in Rekey Fields

The system displays the default values in the following fields. However, you can modify them.

To view the joint holder’s details of an account and the mode of operation maintained at the account level, place the cursor on the Debit Account or Credit Account field and press Ctrl+J. The system displays the ‘Joint Holder’ screen.

For more information on the ‘Joint Holder’ screen refer to the section ‘Joint Holder Maintenance’ in the Core User Manual.

Generate Message

You can control the generation of payment messages for events at the contract level by checking or un-checking this option. By default, this checkbox is unchecked. However, you can check this box to generate payment messages for contracts upon authorization.

5.25.4 Verifying Transaction

After you have displayed the details of the transaction in the FT Contract Authorization screen, you can verify the displayed details to ensure their correctness.

The contract will be displayed in view mode in the ‘FT Contract Online’ screen if invoked from the authorization screen.

5.25.5 Rejecting Transaction

During verification, if any details are found to be incorrect, you can reject the transaction. You must specify your reasons for rejection, as mandatory information.

If you wish to reject the transaction, click ‘Reject’ button in the Contract Authorization screen.

A rejected transaction is marked for repair by the system, with the reasons for rejection you have specified. Such a transaction is marked as one that has ‘failed verification’.

Any user with appropriate ‘amend’ or ‘delete’ rights can retrieve a transaction that has ‘failed verification’ in the Funds Transfer Summary screen, and make changes to it, or delete it.

Oracle FLEXCUBE maintains an audit log of transactions that are rejected. The following details are stored for each rejected transaction:

5.25.6 Amending Transaction that has ‘failed verification’

To recall, any user with appropriate ‘amend’ rights can retrieve a transaction that has ‘failed verification’ in the Funds Transfer Summary screen, and make changes to it.

5.25.7 Deleting Transaction that has ‘failed verification’

A user with appropriate ‘delete’ rights can retrieve a transaction that has ‘failed verification’ in the Funds Transfer Summary screen, and delete it. Oracle FLEXCUBE records the following details as part of the audit trail when a ‘failed verification’ transaction is deleted:

These details can be found in the SMS Exception Report

5.25.8 Authorizing Verified Transaction

If the details of a transaction are found to be correct in all respects during verification, you can authorize it. Use the ‘Authorize’ button in the FT Contract Authorization screen to perform the authorization. This is considered to be the final authorization for the transaction.

Note

At any point during the verification and authorization process, you can cancel the entire operation without affecting the status of the transaction. Close the window to cancel the operation.

You cannot authorise a contract in the following cases:

5.26 Multi-level Authorization of a Contract

High value contracts may require multilevel of authorization. The levels of authorizations are defined in the ‘Product Transaction Limits’ screen. You can use the ‘Multilevel Authorization Detailed’ screen for authoring a contract n-1 times.

However, final authorization can take place only in the contract screen.

For more details, refer the ‘Multilevel Authorization of Contract/Loan Account’ section in the ‘Procedures’ User Manual.

5.27 Transaction Queues (Transaction Status) Manage­ment

The status of a funds transfer transaction (which appears in the right bottom of the FT contract screen) indicates the stage in the processing cycle in which the transaction currently stands. The status also indicates the operations that are possible on a funds transfer transaction with respect to its processing. This is distinct from the ‘Contract Status’ which can be any of Y, A, L, V or H (standing for yet to be Initiated, Active, Liquidated, Reversed and Hold).

Funds transfer transactions that have been entered manually can be in any of the following (process) statuses:

The table below explains the operations that are possible on a funds transfer transaction when it is in any of the states listed above:

Status

Explanation

Possible Course of Action

Processed

This is the logical end-state of a transac­tion. All accounting/ messaging has been processed.

None

Cancelled

Contracts that are deleted before authori­zation will be in this status.

None

Suppressed

Contract which is reversed after authori­zation will be in this status

None

Funding Exception

When contract processing results in account being debited more than the available balance, the contract will be in this status

Funding exception con­tract needs to be author­ized.

Pending Release

Future valued FT input manually and awaiting payment value date will be in this status.

On the relevant BOD, the contract would get auto­matically processed.

 

No

Leave the message as it is; message gets picked up on the value date

Pending Authorization

Transaction awaiting authorization (after input)

Authorize the transaction

Failed Verifi­cation

Contract that has been rejected during the contract verification process.

Amend the contract

To view a summary of funds transfer transactions queues, use the Payment Transactions User Summary screen.

The following details are displayed for each transaction in a queue:

5.28 Summary Dash Board for Funds Transfer Transac­tions

To view a summary of funds transfer transactions that has been sorted according to status queues, you can also use the Dash Board Summary screen. In this screen, the following details are displayed for each type of queue:

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

Choosing the transaction currency

Choose to view the transaction queues summary for any transaction currency, or for all currencies.

Choosing the transaction type

To view transaction status queues for manually entered funds transfers chose ‘Manual’ in the ‘Manual/STP’ field. To view transaction status queues for funds transfers uploaded through the STP function chose ‘STP’ in the ‘Manual/STP’ field. To view both types, choose ‘Both’. When you choose, all transaction queues pertaining to the type selected are displayed on the screen.

Viewing Transaction Summaries

To view the transaction summary for each transaction queue for manually entered transactions, click ‘Payment’ button. The FT Summary screen is opened, with transaction-wise details.

To view the transaction summary for each transaction queue for STP transactions, click ‘Message’ button. The Incoming Browser is displayed.

Refreshing the Dash Board Information

Refresh the information displayed in the Dash Board by clicking on the ‘Refresh’ button in the Dash Board Summary screen.

5.29 Examples on how to Enter Details of FT Contracts

We shall now venture into actually entering an FT Contract using Oracle FLEXCUBE.

This section contains the following topics:

5.29.1 Outgoing Customer Transfer

Let us assume that Silas Reed, a customer of your bank (American Bank) requests you to effect a transfer on his behalf for 1000 £ from his USD account (AS1302614) on 03-01-2000 (the value date), to Wendy Klien’s account with Chasebank London as a birthday gift. You will have to effect an outgoing transfer as funds are going out from your bank. You are initiating the transfer on behalf of your customer therefore an MT 100 will be generated as it is a customer transfer.

In order to enter the details of this contract quickly onto the FT contract screens we shall link this contract to a product that you have already created, which caters to outgoing customer transfers. Assume that you had assigned a product code FOCT to the product. So at the product prompt choose FOCT. The system will automatically generate a reference number for the contract; you can specify a reference number of your choice at the User Reference Number prompt. Based on the product you have linked this contract to, the product type is defaulted in the Product type field. In this case it will be Outgoing.

Therefore the debit currency is USD and the credit currency is GBP. Since your customer wishes to transfer 1000 £, enter 1,000.00 at the Credit Amount field. Since we have not checked against the ‘After Rate refresh’ field, the standard rate you specified for the currency pair (here USD-GBP) in the Currency table will be applied to the 1000£. This exchange rate will be displayed in the Exchange Rate field (1.4000000). Based on the exchange rate the system automatically computes the equivalent of 1000 £ in USD (1,400.00 USD). This amount will be displayed in the Debit Amount field.

Therefore you will have to credit the Nostro account of Chasebank London with 1,400.00 USD and credit the account of Silas Reed (AS1302614) for 1000 £ in the Debit account field.

We shall specify that the rates to be applied to the transfer amount are to be picked up as of the Value date and that Messages are to be generated as of Value date.

The value date for the contract is 03-JAN-2000. Based on the Spot date you specified for the USD, the value date will be defaulted. For our example assume that the Spot date maintained for USD is 2 days. Therefore the Value date is 05-JAN-2000.

Since the transfer is not effected through a Managers check or a Check, you need not enter anything in these fields, as they are not applicable to the transfer you are entering.

For the charges incurred to effect the transfer, let us charge the Remitter (Silas Reed). Therefore you will have to choose Remitter Our Charge in the Charge Bearer field.

Under Payment Details you can specify information that Silas Reed would like to send to Wendy Klien, as to the reason of the payment. In this case you can specify Birthday Gift in this field.

In the By Order of Field you can specify the name and address of Silas Reed, who is the ordering Customer. At Ultimate Beneficiary Details you can specify the name and address of Wendy Klien (the Ultimate Beneficiary of the transfer).

A screen depicting the entries that you will have to make, on the FT Contract screens to effect this transfer successfully, has been captured below:

Earlier we had specified that the Rates and Message as of to be Value date. Therefore the rates to be applied to the transfer amount will be applied on 05-JAN-00, and an MT 100 (payment order) from American Bank, NY, will be sent to Chasebank, London, on 05-JAN-00.

Viewing the Settlement Route of the transfer

In the Settlement Route screen you can view the route that the transfer will take before it actually reaches Wendy Klien. In our case American Bank has a Correspondent relationship with Chasebank, London. Therefore funds will pass from the account of Silas Reed (the ordering Customer) with American Bank, NY, to Chasebank, London. Chasebank will in turn credit the account of Wendy Klien.

Specifying Settlement Details for the transfer

So far, we have discussed the basic information about a transfer, which is captured through the Funds Transfer Contract Details screen. Click ‘Settlement’ button to invoke the settlement screen.

Specifying Account Details for the transfer

The details of the two accounts, involved in the transfer will be displayed. In our example Silas Reed bears the charges incurred to effect the transfer. Therefore Silas Reed’s account together with the currency of the account to be debited for charges will be displayed. Here you can view details for each component item applicable to this transfer.

Verifying signatures online

You can choose to verify customer signatures while you are processing a debit transaction involving a customer account. You can also choose to verify signatures while initiating a DD, a telegraphic transfer, or a Charge payment. Click ‘Signature Verification’ button in the ‘Settlement Details – Account Details’ screen. The Signature Verification screen will be displayed.

 

In this screen all the relevant details pertaining to the particular account signatory will be displayed. You can verify the account signatory details you have received against the details available in the instrument.

Specifying Message Details for a transfer

We shall settle this contract by means of a message. Therefore click on the radio button next to Message. The payment message you specified on the Contract Main screen will be defaulted here.

Since the funds in our example move from the account of Silas Reed (a non-financial institution) with American Bank, NY, to the account of Wendy Klien (a non-financial institution) with Chasebank, London; it is a customer transfer. Therefore an MT 103 (Payment Order) will be generated.

Specifying Party details for the transfer

You have two tabs to specify the parties’ details. You can specify the name and address of the following parties in these screens.

Cover Parties

Specify the local clearing external counterparty details, such as the counterparty name and account details etc. You need to specify this if a cover is required for the contract.

Other Details

The system displays the default details as mentioned in the settlement instruction maintained for the customer, currency, product and module combination. The details specified in the respective fields are used in the message MT103.

Specifying the tax applicable for the transfer

Now in order to specify the tax that is applicable to the contract we you are entering click ‘Tax’ button on the Contract Main screen. Here, the tax specifications you made for the product to which this contract is linked will be defaulted. You can waive the tax to be levied on the transfer amount. To do so, click against the box next to Waive All.

Specifying the charges that are to be collected to effect the transfer

Click ‘Tax’ button in the Funds Transfer Contract Input screen to specify the charges and fees that are applicable to the transfer. Here, all the details of the charges applicable to the transfer you have entered are displayed. You can choose to waive them or charge Silas Reed for them.

You can choose to waive the charge levied on the component. Check against the Waiver option for COMPST. The specified tax will be waived.

After you have defined all, the relevant details of the transfer you can save it either by Selecting ‘Save’ from the Actions menu in the Application tool bar or clicking save icon.

5.29.1.1 Bank Transfer

The Aragones Bank requests Edward Fowles Bank, London to transfer USD 10000 to the account of beneficiary institution Noble Financial Services with Anton Miller Bank, London. The transfer is to be made effective on 3rd June 2001.

Edward Fowles Bank has a correspondent relationship with Anton Miller Bank, London, and therefore, no cover is required for the funds transfer message.

The charges are to be borne by Aragones Bank. A Payment Order, MT 100 must be generated on the value date of the contract, from Edward Fowles Bank London, to Anton Miller Bank, London.

The parties involved are as follows:

Party

Name

Ordering Institution

Aragones Bank

Sender

Edward Fowles Bank, Lon­don

Receiver

Anton Miller Bank, London

Account with Institu­tion

Anton Miller Bank, London

Beneficiary

Noble Financial Services

Your specifications in the Funds Transfer Input Screen would be as follows:

Field

Entry

Product

Outgoing Bank Transfer Type of Product (for example, if you have maintained a product with the code FBTO for outgoing bank trans­fers, then you can select it here)

Debit Currency

USD

Credit Currency

USD

Credit Amount

10000

Debit Account

The account of Aragones Bank in Edward Fowles Bank (say ARAG005)

Credit Account

The account of Noble Financial Services in Anton Miller Bank (say NFS005)

Value Date

03-06-2001

Charge Bearer

Remitter – Our Charges

Message as of

Value Date

Payment Details

The reason for the transfer could be mentioned here, for instance, ‘payment for delivery of goods’

By Order Of

Aragones Bank, London

Ultimate Benefi­ciary Details

Noble Financial Services

Account with Institution

Anton Miller Bank, London

Receiver

Anton Miller Bank, London

Your specifications in the Settlement Message Details screen would be as follows:

Message Details tab

Field

Entry

Payment By

Message

Details of Payment

The reason for the transfer, which you had specified in the Payment Details field in the main Contract Input screen, is defaulted here

The first Parties tab:

Field

Entry

Account With Insti­tution

Anton Miller Bank, London (this information is defaulted in this field, from the main Contract Input screen)

 

The second Parties tab:

Field

Entry

Ordering Institu­tion

Aragones Bank. Typically, this information is defaulted here from the main Contract Input screen

Beneficiary Institu­tion

Anton Miller Bank. Again, this information is defaulted here from the main Contract Input screen

 

5.29.1.2 Outgoing Customer Transfer with Cover

Mr. Albert Williams asks Fina Bank, London to transfer USD 10000 to the account of Mr. Alfred Werker with Gemm Bank, London. Fina Bank, London does not have an accounting relationship with Gemm Bank. Therefore, it will route the payment through CSN Global Bank, London.

The transfer is to be made effective on 22nd September 2001. The charges are to be borne by the beneficiary.

An MT 103 will be generated as on the value date, from Fina Bank, London, to Gemm Bank, London. Also, a cover message will be sent to CSN Global Bank London, as on the value date.

The parties involved are as follows:

Party

Name

Ordering Customer

Mr. Albert Williams

Sender

Fina Bank, London

Sender’s Correspond­ent

CSN Global Bank, Lon­don

Receiver

Gemm Bank, London

Account with Institution

Gemm Bank, London

Beneficiary Institution

Gemm Bank, London

Beneficiary

Mr. Alfred Werker

Your specifications in the Funds Transfer Input Screen would be as follows:

Field

Entry

Product

Incoming Customer Transfer with Cover Type of Product (for exam­ple, if you have maintained a product with the code FCCO for outgo­ing customer transfers with cover, then you can select it here)

Debit Cur­rency

USD

Credit Cur­rency

USD

Credit Amount

10000

Debit Account

Mr. Albert Williams’ account in Fina Bank, London

Credit Account

Mr. Alfred Werker’s account in Gemm Bank, London

Value Date

22-09-2001

Charge Bearer

Beneficiary – All Charges

Message as of

Value Date

Payment Details

The reason for the transfer could be mentioned here

By Order Of

Mr. Alfred Williams

Ultimate Ben­eficiary Details

Mr. Alfred Werker

Account with Institution

Gemm Bank, London

Receiver

Gemm Bank, London

In the Settlement Route tab, you can view the Sender’s Correspondent (CSN Global Bank) in the Our Correspondent field.

Your specifications in the Settlement Message Details screen would be as follows:

Message Details tab:

Field

Entry

Payment By

Message

Details of Payment

The reason for the transfer, which you had specified in the Payment Details field in the main Contract Input screen, is defaulted here

 

The first Parties tab:

Field

Entry

Account With Insti­tution

Gemm Bank, London (this information is defaulted in this field, from the main Contract Input screen)

 

The second Parties tab:

Field

Entry

Ordering Institu­tion

Fina Bank, London. Typically, this information is defaulted here from the main Contract Input screen

Beneficiary Insti­tution

Gemm Bank, London. Again, this information is defaulted here from the main Contract Input screen

 

The Cover Parties tab:

Field

Entry

Beneficiary Institution for Cover

CSN Global Bank, London. Typically, this information is defaulted here from the main Contract Input screen

 

5.29.2 Outgoing Bank Transfer for Own Account

Barclays Bank, London holds the nostro account with Chase bank, Manhattan and Citi Bank, New Jersey. It wants to transfer USD 100000 from Chase Manhattan’s account to Citi Bank in New Jersey. The transfer is to be made effective on 15th December, 2001.

So, in order to process this transfer, Barclays Bank credits Chase Manhattan’s replicated account in its books and debits Citi Bank’s replicated account in its books. In the same process it sends out an Outgoing MT 200 to Chase Manhattan Bank.

When Chase Manhattan Bank receives the Incoming MT 200 from Barclays London, it debits the nostro of Barclays London and sends out an MT 202 to Citi Bank, New Jersey.

Also Citi Bank, New Jersey will receive an MT 210 (Receive Notice).

The parties involved in the contract are as follows:

Party

Name

Sender

Barclays Bank , Lon­don

Receiver

Chase Bank, London

Account with Institu­tion

Citi Bank, New Jersey

Your specifications in the Funds Transfer Input Screen would be as follows:

Field

Entry

Product

Bank transfer for Own Account (E.g.: FBTO – Bank Transfer For Own account Transfer Type of Product).

Debit Currency

USD

Credit Currency

USD

Credit Amount

100000

Debit Account

Citi Bank, New Jersey’s Nostro Account

Credit Account

Chase Bank, Manhanttan’s Nostro Account

Value Date

15-12-2001

Message as of

Booking Date

Account with Institution

Citi Bank .New Jersey

Receiver

Chase Bank , Manhattan

Your specifications in the Settlement Message Details screen would be as follows:

The first Parties tab:

Field

Entry

Account With Institution

Citi Bank, New Jersey (this information is defaulted in this field, from the main Contract Input screen)

 

The second Parties tab:

Field

Entry

Ordering Institu­tion

Barclays Bank, London. Typically, this information is defaulted here from the main Contract Input screen

Beneficiary Institution

Citi Bank, New Jersey. Again, this information is defaulted here from the main Contract Input screen

 

5.29.2.1 Incoming Customer Transfer

Mrs. Catherine Crenshaw asks Fina Bank, London to transfer USD 10000 to the account of Mrs. Wendy Klein with Gemm Bank, London. At Gemm Bank, this is an incoming transfer and the bank receives an incoming message from Fina Bank for the same.

The transfer is to be made effective on 15th December, 2001. The charges are to be borne by the beneficiary.

Gemm Bank receives an MT 103 from Fina Bank, as on the value date of the contract. Gemm Bank also receives an MT 202, for transfer with cover.

The parties involved in the contract are as follows:

Party

Name

Ordering Customer

Mrs. Catherine Cren­shaw

Sender

Fina Bank, London

Receiver

Gemm Bank, London

Account with Institu­tion

Gemm Bank, London

Beneficiary

Mrs. Wendy Klein

Your specifications in the Funds Transfer Input Screen would be as follows:

Field

Entry

Product

Incoming Customer Transfer Type of Product (for example, if you have maintained a product with the code FICO for incoming cus­tomer transfers, then you can select it here)

Debit Currency

USD

Credit Cur­rency

USD

Credit Amount

10000

Debit Account

Mrs. Catherine Crenshaw’s account in Fina Bank, London

Credit Account

Mrs. Wendy Klein’s account in Gemm Bank, London

Value Date

15-12-2001

Charge Bearer

Beneficiary – All Charges

Message as of

Value Date

Payment Details

The reason for the transfer could be mentioned here

By Order Of

Mrs. Catherine Crenshaw

Ultimate Bene­ficiary Details

Mrs. Wendy Klein

Account with Institution

Gemm Bank, London

Receiver

Gemm Bank, London

Your specifications in the Settlement Message Details screen would be as follows:

Message Details tab:

Field

Entry

Payment By

Message

Details of Payment

The reason for the transfer, which you had specified in the Payment Details field in the main Contract Input screen, is defaulted here

 

The first Parties tab:

Field

Entry

Account With Insti­tution

Gemm Bank, London (this information is defaulted in this field, from the main Contract Input screen)

 

The second Parties tab:

Field

Entry

Ordering Institu­tion

Fina Bank, London. Typically, this information is defaulted here from the main Contract Input screen

Beneficiary Insti­tution

Gemm Bank, London. Again, this information is defaulted here from the main Contract Input screen

 

5.30 Authorize Bulk FT Contracts

This section contains the following topics:

5.30.1 Authorizing Bulk FT Contracts

Typically, FT contracts have to be authorized in the respective Contract Online (Summary) screens. This method of authorizing the contracts can be quite cumbersome, especially if the volume of transactions is large. In view of this, Oracle FLEXCUBE allows bulk authorization of all unauthorized FT contracts from the ‘Bulk Authorization Detailed’ screen.

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

Select a module from the drop-down list and click ‘Fetch’ button to get the details of unauthorized FT contracts.

This screen has the following features:

Note

Contracts with mandatory re-key fields would be displayed here, but without the re-key op­tion being available. Global Interdict check would also not be available.

5.30.2 Indicating Ignore Overrides

Indicate whether or not overrides should be ignored during authorization of the contract. If this option is unchecked, and if there are any overrides for which confirmation or dual authorization is required, then the contract will be skipped with an error ‘Overrides not confirmed’ upon authorization. Otherwise, the contracts will be authorized without generating errors.

5.30.3 Indicating Generate Messages

Control the generation of payment messages for events at the contract level by checking or unchecking this option. Checking this box will generate payment messages for contracts upon authorization.

5.30.4 Authorizing Contracts

You can either opt to authorize all the contracts that are displayed or choose only certain contracts for authorization.

After selecting the contracts, click ‘Authorize’ button to authorize the contracts.

5.30.5 Viewing Errors

If the system encounters any errors during the authorization of a particular contract, it will record the error and move on to the next contract.

Click the ‘View Error’ button to view the details of the errors recorded. In this screen, system will display the reference number of the contracts, which could not be authorized, and the reason for the failure of the authorization.

5.30.6 Viewing Settlement Details

The settlement account details of each contract will be displayed in the ‘Settlement Instructions section of the Bulk Authorization Detailed screen. Click on the contract for which you want to view the settlement details and it will be displayed in the ‘Settlement Instructions’ section. For each amount tag, the following settlement details are displayed:

Note

The settlement details for the latest event of the contract are displayed.

5.30.6.1 Fund Asset Management

The settlements processing is enabled only if ‘Allow Corporate Access’ has been checked while defining branch parameters in the Branch Parameters – Detail View screen.

5.30.7 Viewing Contract Details

The details of the unauthorized contracts can be viewed by selecting the contract reference number in this screen.

5.31 Maintaining MT101 Agreements with Ordering Cus­tomer

You can maintain agreements with the ordering customer for MT101 through the ‘MT101 Customer Agreements’ screen. You can invoke the ‘MT101 Customer Agreements’ screen by typing ‘FTDCXFRA’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

You need to capture the following information in this screen:

Customer Number

Specify the customer number.

Incoming MT101

Select this option if it is incoming MT101.

Outgoing MT101

Select this option if it is outgoing MT101.

Customer Identifier

Here the Instructing Parties authorized to debit Ordering customer’s account for incoming MT101 is listed.

Ordering Customer Identifier

Here the Party Identifiers for the Ordering customer are listed. These identifiers are used to look up the customer no in an Incoming MT101 message.

5.32 MT101 Transaction Input Screen

You can input the details for Outgoing MT101 through the ‘Swift MT101 Outgoing Maintenance’ screen. You can invoke the ‘Swift MT101 Outgoing Maintenance’ screen by typing ‘FTDMT101’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

You need to capture the following information in this screen:

Customer Number

Specify the customer number.

Customer Specified Reference

Provide the reference number of the specified customer.

Senders Reference

On pressing the New button system would generate a reference number which would be populated in the Sender’s reference field. This reference number would be populated in the outgoing MT101 SWIFT message.

Receiver

Specify the receiver number. This field will be populated based on the maintenance in ‘Bilateral Agreement’ Screen.

5.32.0.1 Specifying Instructing Party Details

Specify the following details for the instructing party

Identifier Code

Specify the identifier code of the instructing party. The option list shows only BEIs.

Party Identifier

Specify the party identifier code.

Requested Execution Date

Specify the requested execution date.

Authorization

Specify the additional security provisions.

For instance a digital signature between the ordering customer/instructing party and the account servicing financial institution.

5.32.0.2 Specifying Ordering Customer Details

Specify the following details for the ordering customer

Account Number

Specify the account number of the ordering customer. The option list shows only BEIs.

Identifier Code

Specify the identifier code of the ordering customer.

Party Identifier

Specify the party identifier of the ordering customer.

Address Line

Specify the address of the ordering customer.

5.32.0.3 Specifying Account Servicing Institution Details

Specify the following details for the account servicing institution

National Clearing Code

Specify the national clearing code.

BIC Code

Specify the BIC code.

Transaction Reference Number

Specify the reference number of the transaction.

FX Deal Reference Number

Specify the reference number of the deal.

Transaction Currency

Specify the currency used for transaction.

Transaction Amount

Specify the amount of transaction.

Exchange Rate

Specify the exchange rate.

Other Details

Specify the other details in the following screen. To invoke the ‘Other Details’ screen click ‘Other Details’ button.

 

Here you can maintain the other details for the outgoing MT101.

Click ‘Message’ button to view the SWIFT message generated in the ‘Messages’ screen.

 

Click ‘View Message’ button the following screen will display the full message.

 

5.32.1 Viewing FT Contract

You can view the FT contract using ‘Funds Transfer Contract Summary’ screen. To invoke this screen, type ‘FTSTRONL’ in the field at the top right corner of the Application tool bar and click the adjoining arrow button.

You can click ‘Search’ button to view all the pending functions. However, you can to filter your search based on any of the following criteria:

Authorization Status

Select the authorization status of the contract from the drop-down list.

Process Status

Select the process status from the drop-down list.

Product

Select the product code from the option list.

Consolidated Account Reference

Select the consolidated reference number from the option list.

Debit Amount

Specify the amount debited.

Credit Amount

Specify the amount credited.

Counterparty

Select the contract amount from the option list..

Contract Status

Select the status of the contract for which you want to check the pending function from the drop-down list.

Reference Number

Select the contract reference number from the option list.

User Reference

Select the user reference number from the option list.

Receiver

Select the receiver from the option list.

Source Code

Select the source from the option list.

Debit Consolidation Reference Number

You can specify the console contract reference number. This is used for retrieving the list of contracts for which the corresponding single debit contract has been created.

Debit Currency

Specify the debit currency.

Credit Currency

Specify the credit currency from the option list.

Source Reference

Select the source reference number from the option list from the option list.

Branch

Select the branch code for which you want to check the contract from the option list.

When you click ‘Search’ button the records matching the specified search criteria are displayed. For each record fetched by the system based on your query criteria, the following details are displayed:

Click ‘Advanced Search’ to display the screen below:

You can query a contract based on any of the following details: