10. Straight through Processing – Sequence of Events

10.1 Introduction

To recall, straight through processing of funds transfer contracts begins with an incoming SWIFT message, which is displayed in the Incoming Message Browser.

The Messages sub-system of Oracle FLEXCUBE receives SWIFT messages, and stores them in the incoming directory. The STP function then reads these messages and begins processing them.

After the Messaging system stores incoming SWIFT messages in the incoming directory, the STP function executes the following sequence of events:

  1. Reads the message from the incoming directory and displays it in the Incoming Browser. At this stage, the message is not interpreted or resolved, and the contract details have not been extracted yet. Also, you can view the details of the message in the incoming browser at this stage.
  2. The Message Upload function then interprets the message, extracting the contract details. These details are propagated into the Funds Transfer (FT) Upload tables in the system. These tables, therefore, store the extracted details of the contracts contained in the incoming SWIFT messages. Any default information is appended, and if any message has been rejected for any reasons, or an error has been encountered, the same is logged as an exception.
  3. When the Message Upload function interprets the message, it also resolves the Oracle FLEXCUBE FT product to be used for the contract, using the Product Message Mapping, for the incoming message type. The product code thus resolved is also stored in the FT Upload tables, with the other contract details. Based on the parties in the message, the settlement accounts are also resolved using the data maintained in the Settlement Instructions table.
  4. The Funds Transfer (FT) Upload function creates contracts using the interpreted messages, reading them from the FT Upload tables. This involves matching the extracted contract details with the information fields in Oracle FLEXCUBE, for funds transfer contracts. In the process, the product level and customer level defaults are also picked up for sub-systems such as charges, taxes MIS, etc. If any contract upload gets rejected for any reasons, or if an error is encountered, the same is logged.
  5. Subsequent to the creation of the contracts by the FT Upload function, they can be processed just as any other FT contract in the system, and can be amended, authorized and so on.

This chapter contains the following sections:

10.2 Incoming Message Browser

Incoming SWIFT messages containing details of funds transfer contracts are stored in the incoming directory that you have designated for receiving messages through SWIFT. The incoming browser is therefore the repository of all incoming messages in Oracle FLEXCUBE.

At this stage, the details of the funds transfer contract are not extracted, and the fields in the message that pertain to the funds transfer contract are not yet resolved.

For more information on the structure of the Incoming Browser and the operations that can be performed on the Incoming Message Browser, consult the Messaging system user manual.

As mentioned earlier, the end user queues and the access rights to the users in the department who will need to view the messages should already have been defined for your branch.

10.3 Message Upload Function

When the incoming message is displayed in the incoming browser, the message upload function resolves the contents of the message under the different information heads (fields) in Oracle FLEXCUBE.

The message upload facility of Oracle FLEXCUBE allows you to automatically process all incoming MT 103, MT 103+ and MT 202 messages, which result in either incoming or outgoing Funds Transfers.

Subsequent to the upload, the details of each message will be updated in Oracle FLEXCUBE as an FT contract. After this, the Funds Transfer can be processed as any other contract in Oracle FLEXCUBE.

All the information that you would normally specify in the fields in FT Input Detailed screen when you enter an FT contract, is resolved from the incoming message, by the message upload function. The contents of the message are translated into Oracle FLEXCUBE fields, and populated in the FT upload tables.

The Message Upload function resolves the contents of the incoming message into Oracle FLEXCUBE funds transfer contract field information, but the actual contracts are not created as yet. The creation of the actual contracts is performed by a separate function, the FT Upload function, which is enumerated in the Batch Upload chapter of the Funds Transfer User Manual.

10.3.1 Automatic Execution of Message Upload Function

The upload of MT 101, MT 103, MT 103+ and MT 202 messages by the Message Upload function can either be on-line or can be done as a batch process. If you have specified that the automatic upload of MT 101, MT 103, MT 103+ and 202 messages should be on-line then the Message Upload function will automatically upload and process these S.W.I.F.T messages.

The upload will be in line with the specifications you made for the source, from which the message was uploaded, and will be enriched based on the product linked to the message type.

Note

The contracts uploaded through this process will bear the status (authorized or unauthor­ized) defined for the source from which it is uploaded.

10.4 Interpreting Contents of Incoming Message

While the actual interpretation of the contents of the message depends upon the message type (i.e., whether the message is a 103 or an MT 200 or an MT 202, and so on), a logical sequence of steps is performed irrespective of the message type.

This section contains the following topics:

10.4.1 D to A Conversion

When an incoming SWIFT payment message contains information regarding parties involved in a funds transfer, in the ‘D’ format, i.e., names and addresses, the STP function uses the D to A converter records (which we have discussed earlier) to derive the BIC Codes (A format) for the parties involved in the funds transfer.

The STP function replaces the name and address information (D format) in the message with the corresponding BIC Code (A format), picked up from the converter record.

The name and address information contained in the incoming SWIFT message must be matched exactly, line for line, literally and without case sensitivity, by the address lines information in the converter record, for the corresponding BIC Code to be picked up by the STP function.

10.4.2 Derivation of Debit and Credit Accounts

This is one of the most important steps in the message upload process. It is through this step that the system identifies the accounts that have to be debited and credited for the resultant FT contract.

For instance, if the incoming message is an MT 103 sent by the Bank’s correspondent, which orders the Bank to pay a certain sum to a customer of the Bank, the system (from the message) deciphers that the Debit account is the relevant nostro account (mirror of it’s account with the Sender of the MT 103) and that the Credit account is the relevant customer’s account. The logic for derivation of the debit and credit account depends upon the incoming payment message type, viz. whether the incoming message is an MT 103, 200 or a 202. While derivation of the debit account is primarily driven by the contents of fields 53 to 55 of the incoming message, the derivation of the credit account is primarily driven by the contents of the fields 56 to 59, together with the settlement instructions maintenance table, where the Standard Settlement Instructions are maintained for both Customers and BIC’s.

The step–wise sequence of the derivation logic of both the debit account and credit account is given in Annexure - B of this user manual for each of the incoming payment message types.

10.4.3 Processing ISO 11649 in Field 70

ISO 11649 Creditor Reference number, also referred to as Structured Creditor Reference number, is an International Business Standard and is based on ISO 11649.

The Creditor Reference number is an alphanumeric string with 25 characters in length.

ISO 11649 Creditor Reference, if present in Field 70, will be available in the first line without any characters preceding it and is the only information available in the first line.

If an outgoing MT 101, MT 102, MT 102 +, MT 103, or MT 103 + messages are generated, then the system identifies the ISO 11649 Creditor Reference and validates the following, if specified:

10.4.4 Processing of Field 72

The STP process of Oracle FLEXCUBE will handle the processing of field 72 (Sender to Receiver Information) for all Incoming SWIFT Payment Messages (MT 103, MT 200 and MT 202) based on the abbreviation code associated with field 72. It is also dependent on whether the beneficiary of the payment transaction resides with the Oracle FLEXCUBE bank or not.

Case 1: The processing of field 72 for all payment messages where the beneficiary resides with the Oracle FLEXCUBE bank is summarized in the table below:

SlNo. Field 72 Code Category Field 72 Code Field 72 Code processing for MT 100 Field 72 Code processing for MT 103 Field 72 Code processing for MT 200 Field 72 Code processing for MT 202
1 Par­ties ACC (Info for Acc with Inst) Copy to field 72 of Payment Transaction being created. Copy to field 72 of Pay­ment Transac­tion being created. Copy to field 72 of Payment Transac­tion being created. Copy to field 72 of Pay­ment Trans­action being cre­ated.
2 Par­ties INS (Instruct­ing Inst) Copy to field 72 of Payment Transaction being created. Copy to field 72 of Pay­ment Transac­tion being created. Not Appli­cable Copy to field 72 of Pay­ment Trans­action being cre­ated.
3 Par­ties RCB (Receiver’s Corre­spondent) Try and Derive the Debit Account from contents speci­fied after //RCB. If Debit Account Derivation is successful, then do not copy the code and its contents to field 72 of Payment Transaction being created. Not Applica­ble Not Appli­cable Not Appli­cable
4 Par­ties INT (Info for Intermedi­ary) Not Applicable Copy to field 72 of Pay­ment Transac­tion being created. Copy to field 72 of Payment Transac­tion being created. Copy to field 72 of Pay­ment Trans­action being cre­ated.
5 Par­ties REC (Info for Receiver of Payment) Not Applicable Mark Incom­ing SWIFT Pay­ment Mes­sage for Repair with an appropri­ate repair reason. Mark Incoming SWIFT Payment Message for Repair with an appropri­ate repair reason. Mark Incom­ing SWIFT Pay­ment Mes­sage for Repair with an appro­priate repair reason.
6 Par­ties BNF (Info for Benefi­ciary) Not Applicable Not Applica­ble Not Appli­cable Copy to field 72 of Pay­ment Trans­action being cre­ated.
7 Method of Pay­ment BENONLY (Payment for Ben only) Copy to field 72 of Payment Transaction being created. Not Applica­ble Not Appli­cable Not Appli­cable
8 Method of Pay­ment CHEQUE (Payment by cheque only) Copy to field 72 of Payment Transaction being created. Not Applica­ble Not Appli­cable Not Appli­cable
9 Method of Pay­ment CORPTRAD (FX Settle­ment) Copy to field 72 of Payment Transaction being created. Not Applica­ble Not Appli­cable Not Appli­cable
10 Method of Pay­ment HOLD (Pay upon customer ID) Copy to field 72 of Payment Transaction being created. Not Applica­ble Not Appli­cable Not Appli­cable
11 Method of Pay­ment INTRA­COM Copy to field 72 of Payment Transaction being created. Not Applica­ble Not Appli­cable Not Appli­cable
12 Method of Advice PHON (Advise Acc with Inst by phone) Copy to field 72 of Payment Transaction being created. Not Applica­ble Copy to field 72 of Payment Transac­tion being created. Copy to field 72 of Pay­ment Trans­action being cre­ated.
13 Method of Advice PHONBEN (Advise Ben by phone) Copy to field 72 of Payment Transaction being created. Not Applica­ble Not Appli­cable Copy to field 72 of Pay­ment Trans­action being cre­ated.
14 Method of Advice PHONIBK (Advise Intermedi­ary by phone) Copy to field 72 of Payment Transaction being created. Not Applica­ble Copy to field 72 of Payment Transac­tion being created. Copy to field 72 of Pay­ment Trans­action being cre­ated.
15 Method of Advice TELE (Advise Acc with Inst) Copy to field 72 of Payment Transaction being created. Not Applica­ble Copy to field 72 of Payment Transac­tion being created. Copy to field 72 of Pay­ment Trans­action being cre­ated.
16 Method of Advice TELEBEN (Advise Ben) Copy to field 72 of Payment Transaction being created. Not Applica­ble Not Appli­cable Copy to field 72 of Pay­ment Trans­action being cre­ated.
17 Method of Advice TELEIBK (Advise Intermedi­ary) Copy to field 72 of Payment Transaction being created. Not Applica­ble Copy to field 72 of Payment Transac­tion being created. Copy to field 72 of Pay­ment Trans­action being cre­ated.

 

Case 2: The processing of field 72 for all payment messages where the beneficiary does not reside with the Oracle FLEXCUBE bank is summarized in the table below:

Field 72 Code Category Field 72 Code Field 72 Code processing for MT 100 Field 72 Code processing for MT 103 Field 72 Code processing for MT 202 Field 72 Code processing for MT 200
Parties ACC (Info for Acc with Inst) Mark Incoming SWIFT Message for Repair with appropriate repair reason. Mark Incom­ing SWIFT Message for Repair with appropriate repair rea­son. Mark Incoming SWIFT Message for Repair with appropri­ate repair reason. Not Appli­cable
Parties INS (Instructing Inst) Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Copy to field 72 of Pay­ment Trans­action being created & process Incoming SWIFT Mes­sage. Copy to field 72 of Payment Transac­tion being created & process Incoming SWIFT Message. Not Appli­cable
Parties RCB (Receiver’s Correspond­ent) Try and Derive the Debit Account from contents specified after //RCB. If Debit Account Deriva­tion is successful, then do not copy the code and its contents to field 72 of Payment Transaction being created else mark SWIFT Message for Repair. Not Applica­ble Not Appli­cable Not Appli­cable
Parties INT (Info for Inter­mediary) Not Applicable Copy to field 72 of Pay­ment Trans­action being created & process Incoming SWIFT Mes­sage. Copy to field 72 of Payment Transac­tion being created & process Incoming SWIFT Message. Not Appli­cable
Parties REC (Info for Receiver of Payment) Not Applicable Mark Incom­ing SWIFT Message for Repair if line no. 2 of field 72 does not contain a valid SAP Code. Mark Incoming SWIFT Message for Repair if line no. 2 of field 72 does not contain a valid SAP Code. Not Appli­cable
Parties BNF (Info for Ben­eficiary) Not Applicable Not Applica­ble Copy to field 72 of Payment Transac­tion being created & process Incoming SWIFT Message. Not Appli­cable
Method of Pay­ment BENONLY (Payment for Ben only) Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Not Applica­ble Not Appli­cable Not Appli­cable
Method of Pay­ment CHEQUE (Payment by cheque only) Mark Incoming SWIFT Message for Repair with appropriate repair reason. Not Applica­ble Not Appli­cable Not Appli­cable
Method of Pay­ment CORPTRAD (FX Settle­ment) Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Not Applica­ble Not Appli­cable Not Appli­cable
Method of Pay­ment HOLD (Pay upon customer ID) Mark Incoming SWIFT Message for Repair with appropriate repair reason. Not Applica­ble Not Appli­cable Not Appli­cable
Method of Pay­ment INTRACOM Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Not Applica­ble Not Appli­cable Not Appli­cable
Method of Advice PHON (Advise Acc with Inst by phone) Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Not Applica­ble Copy to field 72 of Payment Transac­tion being created & process Incoming SWIFT Message. Not Appli­cable
Method of Advice PHONBEN (Advise Ben by phone) Mark Incoming SWIFT Message for Repair with appropriate repair reason. Not Applica­ble Mark Incoming SWIFT Message for Repair with appropri­ate repair reason. Not Appli­cable
Method of Advice PHONIBK (Advise Inter­mediary by phone) Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Not Applica­ble Copy to field 72 of Payment Transac­tion being created & process Incoming SWIFT Message. Not Appli­cable
Method of Advice TELE (Advise Acc with Inst) Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Not Applica­ble Copy to field 72 of Payment Transac­tion being created & process Incoming SWIFT Message. Not Appli­cable
Method of Advice TELEBEN (Advise Ben) Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Not Applica­ble Copy to field 72 of Payment Transac­tion being created & process Incoming SWIFT Message. Not Appli­cable
Method of Advice TELEIBK (Advise Inter­mediary) Copy to field 72 of Payment Trans­action being cre­ated & process Incoming SWIFT Message. Not Applica­ble Copy to field 72 of Payment Transac­tion being created & process Incoming SWIFT Message. Not Appli­cable

10.4.5 Processing of ‘BNF’ in Field 72

If the account number field (field 59 for MT 103 & field 58 for MT 202) for an Incoming Payment Message is not populated, the STP process of Oracle FLEXCUBE will automatically route it to the ‘Repair’ queue. It will then check for the presence of the abbreviation code ‘BNF’ (Info for Beneficiary) in field 72 (Sender to Receiver Information) of the message. If the code is found, the system will automatically ignore the non-numeric characters in the code and read only the account number specified after the code. The account number will then be validated in the current branch. If found valid, it will be assigned to field 58 or 59, depending on the message type and subsequently marked as the credit account for the incoming payment transaction.

As the payment transaction is automatically repaired by the system, it will be routed to the ‘Repair’ queue with the repair reason as ‘Auto Repaired’. A user with authorization rights will authorize the Payment Transaction after which the STP process will pick it up for further processing.

If Oracle FLEXCUBE encounters a field 72 abbreviation code that is not listed in the table above, the SWIFT Payment Message will be marked with ‘Repair’ status, indicating the appropriate reason for repair.

10.4.6 Derivation of FT Product

Another key step in the STP process is the association of the payment message with the appropriate FT product.

All Incoming SWIFT Payment Messages can be associated with any one of the following types of Payment Products:

However, the STP process of Oracle FLEXCUBE will first derive the Debit and Credit account for an Incoming SWIFT Payment Message before determining the Payment Product to be associated with it. Based on the type of accounts derived, the process will automatically associate the appropriate type of Payment Product.

The type of Payment Product to be associated based on the derived Credit and Debit Account type for an Incoming SWIFT Payment Message is summarized in the table below:

Debit Account Type Credit Account Type Payment Product Type
Nostro Nostro Outgoing
Nostro Non-Nostro Incoming
Non-Nostro Non-Nostro Internal
Non-Nostro Nostro Outgoing
Internal GL Account Internal GL Account Internal

To recall, you can map a message type to different payment products in the Product Mapping screen. Depending on the product type (Outgoing, Incoming, or Internal), the relevant product is picked up for processing the FT contract.

10.4.7 Build-up of FT Upload Transaction Record

The key details required for the FT contract such as Debit and Credit accounts, the amount and currency of transfer, etc, are derived from the message contents. Once the product is derived, all the product level processing preferences are picked up.

10.5 Validations Performed on Incoming SWIFT Message

As mentioned earlier, the message upload function of Oracle FLEXCUBE will resolve the contents of the SWIFT message, in the Incoming Message Browser. During this process, the system will also perform certain validations on the contents of the message. Only after carrying out the validations, the contents of the message are translated into Oracle FLEXCUBE fields, and populated in the FT upload tables.

Each of these validations is discussed in the subsequent sections of this document

This section contains the following topics:

10.5.1 Validations for Back Value Days

Oracle FLEXCUBE will process back valued SWIFT messages if the value date is within the ‘Back Value Days’ limit maintained for the FT product to which the message is eventually associated.

If the date does not fall within the limits maintained, the message will be marked for ‘Repair’ indicating the appropriate reason for repair. The corresponding error code can be configured alternatively as ‘Override’, in which case Oracle FLEXCUBE will only log an override and go ahead with processing or ‘Ignore’ in which case, the error condition will not affect the processing in any way.

For information on maintaining ‘Back Value Days’ for an FT product, consult the Products chapter of the Funds Transfer User Manual.

10.5.2 Validation of Local Clearing Codes

The STP process of Oracle FLEXCUBE will validate the Local Clearing Codes specified in the fields (56, 57 & 58 – Intermediary Institution, Account with Institution, and Beneficiary Institution) of an Incoming SWIFT Payment Message in the following manner:

Note

The Local Clearing Code is always prefixed by the Local Clearing Code Indicator. For ex­ample, the Local Clearing Code for the clearing agent UK Chaps is ‘//SC23-09-85’ where ‘SC’ is the Clearing Code Indicator and 23-09-85 is the actual Local Clearing Code. The STP process will ignore the first four non-numeric characters (‘\\SC’ in //SC23-09-85) to derive the Clearing Code. The Clearing Code derived thus should conform to the mask or format specified for the Clearing Code Network to which it belongs.

Note

You can maintain ‘Own Local Clearing Codes’ for all Local Clearing Codes within the same network. If in an Incoming SWIFT Message, the same bank is the beneficiary institution as well as the receiver of funds, the STP process will assign the Own Local Clearing Code to the party fields of the resultant outgoing payment message.

10.5.3 Available Balance Check

At the time of processing a SWIFT payment message transaction, the STP process will check for the availability of funds in a customer account when posting an accounting entry.

Note

The STP process will perform the check only if you have selected the ‘Available Balance Check Required’ option for both the Transaction Code associated with the accounting en­try (the transaction code associated with the Debit leg of the transaction in the Product Event Definition) and the Customer Account Class to which the customer account that is being debited, belongs.

10.5.3.1 Handling Failure of Available Balance Checks by STP

In the event the available balance check fails for an Incoming SWIFT Payment Message transaction, the STP process of Oracle FLEXCUBE will automatically move such transactions to the ‘Funding Exception’ status. The corresponding error code can be configured alternatively as ‘Override’, in which case Oracle FLEXCUBE will only log an override and go ahead with processing or “Ignore” in which case, the error condition will not affect the processing in any way.

Oracle FLEXCUBE also enables users with appropriate rights to ‘Force Release’ all Payment Message Transactions with ‘Funding Exception’ status and insufficient funds to the Incoming Message Browser. In other words, the system will post the required accounting entries for such transactions regardless of insufficient funds in the accounts. The system will also maintain a detailed audit trail for such transactions.

10.5.4 Currency Cut-off Checks

The STP process of Oracle FLEXCUBE performs the currency cut-off checks for all Incoming SWIFT Payment Messages. The message is validated against the cut-off days and cut-off time specified for the customer, product and currency involved in the payment message.

Note

The cut-off checks are performed only if applicable for the product derived during the pro­cessing of the Incoming SWIFT Message.

For details on maintaining Cut-Off Times and Cut-Off Days for a currency, refer the Core Services User Manual.

If the SWIFT message fails the currency cut-off checks, the system displays an override message. You can configure the override as an error message or a warning, depending on your requirement.

10.5.5 Processing Uploaded Future Valued Payment Message Transaction

If the value date of a SWIFT payment message transaction is a date in the future, it is referred to as a ‘Future Valued’ transaction. The STP process updates the status of such payment messages to ‘Pending Release’. The system does not generate the accounting entries and payment advices for transactions that are future valued and subsequently, pending release. The system also defers the currency cut-off check for future valued transactions.

10.5.5.1 Processing Payment Transactions with Pending Release Status

The batch processing function run at BOD (Beginning of Day) will check all future valued payment transactions. It will then release those transactions whose value date are earlier than or equal to the current system date. The batch processing function will also check for the availability of funds before posting the required accounting entries and subsequently, generates the outgoing payment advices for all transactions that are released on the day.

The currency cut-off checks will also be performed on the value date.

10.5.6 Exchange Rates Default for Cross-Currency STP Transactions

You can place restrictions on the amount involved in cross currency payment message transactions that are uploaded by the Oracle FLEXCUBE STP process.

Note

The ‘Exchange Rate Limits’ maintained for the relevant branch, currency, and product combination will be used to perform the check.

At the time of uploading cross-currency payment message transactions, the STP process will validate the limits in the following manner:

10.5.7 Checking for Blocked BIC Codes

At the time of processing a SWIFT Payment Message, if the STP process encounters messages involving SWIFT BIC Codes (in the fields containing party information) that have been blocked (or blacklisted), the system will mark the message with a ‘Repair’ status along with the appropriate reason for repair.

The corresponding error code can be configured alternatively as ‘Override’, in which case Oracle FLEXCUBE will only log an override and go ahead with processing or ‘Ignore’ in which case, the error condition will not affect the processing in any way.

The STP will check for blocked BIC codes in following fields of a payment message:

10.5.8 Validating Transfer Currency and Account Currency

For messaging resulting in an incoming transfer, if transfer currency differs from the account currency for incoming transfer, the corresponding message goes to the repair queue.

The upload process of incoming message provides a validation of account currency with transfer currency. If the currencies are different, the message is routed to the repair queue. The error-code is configurable to be either an Error or Override, depending upon your installation.

10.5.9 Validating Credit Card Payments

Oracle FLEXCUBE provides a facility to processes incoming Credit Card payments through SWIFT message. The system processes these FT messages as follows:

  1. External Bank initiates Credit Card payment and the system receives an incoming swift message for FT payment.
  2. System validates this incoming message against the rule maintained for Field 59 for the existence of Credit Card account and status.
  3. If the validation is successful, the system posts the message to an appropriate queue maintained for Credit Card incoming FT payment.
  4. Based on the queue type, the system triggers the appropriate FT product maintained for Credit Card.
  5. Triggered FT product initiates the FT transaction by debiting the NOSTRO account and crediting the card product GL.
  6. After successful transaction, the system generates an advice based on the following details:

10.6 Cover Matching

This section contains the following topics:

10.6.1 Detection of Messages for ‘Pending Cover’ Status

If an incoming MT 103/MT 202 is in the Local Currency of the branch where it is received and the Sender of the message does not have the authority to specify the Debit Account for the message, the system will automatically route the message to the ‘Pending Cover Queue’.

If the STP process detects an Incoming SWIFT Payment Message (MT 103/ MT 202) with the status as ‘Pending Cover Match’, the message is kept on hold until a ‘Payment Cover Message’ (MT 202/MT205) is received from the Intermediary bank. Upon receipt of a Payment Cover Message, it is automatically matched with the Payment Message that is on hold. After it is matched, the Payment Cover Message is suppressed and Payment Message that was on hold is picked up for processing.

If the system uploads an MT205 first, the message will be suppressed and though a matching MT103/202 is uploaded later, the auto cover matching will not take place.

Note

When the existing MT103 is received from anyone other than our correspondents, then the MT 103 message will be moved to a Cover matching queue (which is a user maintained queue) with the status mapped as ‘Pending Cover match’. (Status =’C’, Process Status =’R’, Force Cover Match =’N’)

Once the MT 202 is identified as the cover message, the MT 202 will be suppressed. (Status = ‘S’, Process Status =’P’, Suppress_message = ‘F’ – indicating Full suppress). Also MT 103 will be moved from the Cover match queue and processed.

10.6.1.1 Processing of MT 910

The processing of Cover Matching can also be done when an Incoming MT 910 is received based on the following conditions-

When the MT 910 is received and the above mentioned conditions are satisfied, then MT 910 are suppressed and the corresponding MT 100 / MT 103 are processed.

You can send an MT 202 either as a Payment Cover Message or a normal Payment Message. The system will identify the MT 202 as a Payment Cover Message if it satisfies the following conditions:

Note

‘Payment Cover Messages’ are always received later than the related SWIFT Payment Messages.

10.6.2 Matching Payment Message with its Cover

After the receipt of the ‘Payment Cover Message’, the STP process matches it with a normal SWIFT Payment Message that satisfies the following conditions:

The STP process may encounter one of the following three conditions, in its search for a related Normal Payment Message that matches with a Payment Cover Message (MT 202).

Processing an MT 202 with more than one matching Payment Message

If the STP process detects more than one related normal Payment Message matching the above conditions, the Payment Cover Message is moved to the ‘Repair’ status and the appropriate reason for repair is also indicated. The user will manually process all the normal Payment Messages matching the Payment Cover Message.

Processing an MT 202 with a single matching Payment Message

If the STP process finds a single related Normal Payment Message that matches the above conditions, the Payment Cover Message is marked as ‘Matched’ and its status is updated to ‘Suppressed’. The related Payment Message (100 or 103) is also marked as ‘Matched’ and it is moved from the Cover Queue to the unprocessed queue from where the STP picks it up for further processing.

Processing an MT 202 without a matching Payment Message

If the Oracle FLEXCUBE STP process does not find any related Payment Messages matching the above-mentioned criteria, it will check for the presence of field 72 (Sender to Receiver Information) in the Payment Cover Message. If field 72 does not exist, the system will automatically suppress the Payment Cover Message and maintain a detailed audit trail for the same. The suppressed Payment Cover Message will not require any further verification.

If field 72 exists in the Payment Cover Message, the STP process will automatically route the Payment Cover Message to the ‘Repair’ queue indicating the appropriate reason for repair.

10.7 Payment Cover (MT 202) Generation Rules

Oracle FLEXCUBE STP process will automatically generate an Outgoing Payment Cover Message (MT 202) if the following criteria are satisfied:

10.7.1 Incoming MT 202

For an incoming MT202, the system determines the Queue while uploading messages based on the STP Rule maintained for a Message Type. Subsequently, the Product Message mapping information for a particular Queue is used to determine the Module and the Product (in case of FT) or the Product Category (in case of PC) to which the message needs to be routed. Mapping a particular message type for a particular branch to different Queues is possible.

 

10.8 FT Upload Process

The FT upload process is explained in detail in the chapter on FT Upload. The same process gets invoked automatically by the STP process also. The message upload process, described in the previous section, ends with the population of data in the FT upload tables. During the STP process, the next step is the invoking of the FT contract upload function automatically. This function reads the contents of the FT upload tables and creates FT contracts in the system. Once the FT upload process has created a contract, the rest of the life-cycle processing of such contracts (which have come through STP) is identical to contracts created from the Oracle FLEXCUBE front-end or through FT upload.

10.9 Operations on Incoming Message

Oracle FLEXCUBE lets you perform a variety of operations on the incoming messages, such as suppression, amendment, authorization, etc. This section describes these workflow aspects in some detail.

This section contains the following topics:

10.9.1 Handling Exceptions in STP Process (Repair of Messages)

The message upload process takes one message at a time and applies a sequence of logical steps to derive information required to populate FT contract upload tables. In this process it may encounter various errors. These may be due to errors in the incoming SWIFT message itself or errors encountered in processing due to absence of proper maintenance or other exceptional conditions.

If the message upload process encounters an error for a particular message, its processing status is updated automatically to ‘Repair’ and the same is available for the user to view on the incoming message browser. The user can then manually choose to take appropriate action to rectify the situation. The user may choose to input the relevant FT contract (when the message is in repair) manually through the regular contract input function provided by Oracle FLEXCUBE. Alternatively, the user may also like to ’repair’ or correct the incoming message and let Oracle FLEXCUBE try to process the message automatically again.

10.9.1.1 STP Repair Statistics Report

As discussed earlier, the Message Upload Function interprets the Incoming SWIFT Payment Message received by your bank and propagates the interpreted messages into the Funds Transfer (FT) Upload tables in the system. The various errors it encounters during this process are logged in a separate table. Each error is identified by a unique number. The error code and the possible reason for the error are also logged in the table.

You can choose to generate an ‘STP Repair Statistics Report’ from the data logged in the table. Generating such a report will help you in identifying the causes for the errors. The report is generated through Business Objects, a reporting tool. You can choose to generate the report at any point or for a specific period.

10.9.2 Suppression of Incoming SWIFT Payment Messages

You can choose to suppress an Incoming SWIFT Payment Message with the following statuses:

All Incoming SWIFT Messages are displayed in the Incoming Message Browser. To suppress a message, click ‘Suppress’ button in the Incoming Browser. The ‘Suppress Message’ screen is displayed.

The following options are available to suppress a Payment Message:

Specifying the ‘Suppress Message Generation’ option

If you select this option, Oracle FLEXCUBE will stop the generation of the Payment Message. However, the system will post the necessary accounting entries for the messages being suppressed.

Indicating the ‘Suppress Full’ option

If you select the full suppress option for a message, the system will not post the related accounting entries. Advice generation will also be stopped. In other words, the system will not pick up the Payment Message for any further processing.

Specifying the ‘No Suppress’ option

A message marked with the ‘No Suppress’ option will be processed like any other normal Incoming SWIFT Payment Message.

Specifying the remarks for a suppressed message

You can specify the reason for suppressing a Payment Message in the ‘Remarks’ field.

Click ‘Ok’ button to save the details and return to the Incoming Message Browser.

Authorizing Suppressed Message

A different user with appropriate rights will be required to authorize the suppressed Payment Messages. The system will display an appropriate warning message to the authorizer indicating that the Payment Message has been suppressed.

The system will maintain a detailed audit trail along with the suppression remarks for all Incoming SWIFT Payment Messages that have been suppressed.

Note

You will not be allowed to suppress Incoming SWIFT Payment Messages that have al­ready been processed by the system.

10.9.3 Verifying and Authorizing an Incoming SWIFT Payment Message

Oracle FLEXCUBE allows you to amend the details of an Incoming SWIFT Payment Message that is marked for repair.

At the time of amending a SWIFT payment message, you can specify the details of the amendments along with the reasons for carrying out the amendments.

Authorizing Amended SWIFT Payment Message

All the amendments made to a SWIFT payment message, have to be authorized by a user with appropriate authorization rights.

At the time of authorizing, Oracle FLEXCUBE will display the earlier version of the SWIFT payment message along with the amended version, in the same window. A list of all the errors due to which the message was marked for repair is also displayed. The authorizer can view all the errors and also verify the changes that were made to correct them. After verification, if all the details are found to be appropriate, the message is authorized.

Oracle FLEXCUBE maintains a detailed audit log of all amended SWIFT Payment Messages. The following details are captured for each authorized message:

Note

At any point during the verification and authorization process, the authorizer can choose to cancel the entire operation without changing the status of the message.

10.9.3.1 Rejecting Amended SWIFT Payment Message

During verification, if the amendments are found to be inappropriate or wrong, the authorizer can choose to reject the message. The authorizer should specify the reasons for rejection, as mandatory information.

The STP process will update the status of a SWIFT payment message as rejected, specifying the reasons for rejection. A rejected message is marked as one that has ‘failed authorization’. You can perform a query on all messages that have failed authorization, in the Incoming Message Browser.

Oracle FLEXCUBE maintains a detailed audit log of all SWIFT Payment Messages that are rejected along with the reasons for rejection.

10.9.3.2 Amending or Deleting Incoming SWIFT Payment Messages

Any user with appropriate rights can amend or delete a SWIFT Payment Message that has failed authorization or is pending authorization.

Note

Oracle FLEXCUBE will not allow you to delete the first original version of a SWIFT Pay­ment Message received from the SWIFT network.

10.10 Payment Transaction Status Management

The status of a funds transfer transaction 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.

Funds transfers that have been uploaded through the gateway tables using the STP (Straight Through Processing) function can be in any of the following 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 End State? Possible Course of Action Possible Result
Processed Yes None None
Repair No Manual Repair of mes­sage Post correction message goes through the STP pro­cess again.
    Suppress the entire message The entire message is sup­pressed and no further action is taken on the mes­sage
    Suppress the resultant outgoing message but process the accounting Resultant funds transfer contract is created but the messaging is suppressed
Suppressed Yes None None
Funding Excep­tion No Force the message through Transaction will go through with override
Pending Release No ‘Force Release’ the message Transaction will go through with override
  No Leave the message as it is; message gets picked up on the value date Funds transfer contract is created on the value date
Pending Author­ization No Authorize the transac­tion  
Failed Authori­zation No    
Pending Cover Match No    
Unprocessed No Message is picked up for processing  

The system maintains queues of transactions in each status

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

You can set certain filters as follows for viewing the details on this screen:

Once you have set the filters you want, click ‘Refresh’ button to view the payment summary.

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

10.11 Payments Summary Dash Board

To view a summary of funds transfer transactions that has been sorted according to status queues, you can also use the Payments Dash Board screen. 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.

In this screen, the following details are displayed for each type of queue:

Currency

You can choose to view the transaction queues summary for any transaction currency, or for all currencies.

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 STP transactions, click ‘Message’ button. The Incoming Browser is displayed.

Refreshing the Dash Board Information

You can refresh the information displayed in the Dash Board by clicking the ‘Refresh’ button in the Dash Board screen.

10.12 Examples of STP

This Section contains examples of incoming payment messages, a brief illustration of the processing logic and an indication of the resulting outgoing messages and the accounting entries that would get passed. All the examples below draw upon a common set of maintenances assumed to have been done in the system as detailed below:

This section contains the following topics:

10.12.1 Maintenance (assumed for illustration purposes)

Assume that the following maintenance has been done in the system.

10.12.1.1 Customers and Customer Accounts

Customer type Customer Name CIF ID BIC Account Type Account Ccy Account ID
Bank MID­LAND BANK MIDLB00 MIDLGB2A Current GBP MIDLGB00BK­CU1GBPxA
Individual PETER SMITH PSMIT10   Savings GBP PSMIT10INDSB1GBPaD
Individual JOHN BULL JBULL10   Savings USD JBULL10INDSB1USDaD
  Bank CITIB­ANK CIT­IB10 CIT­IUS33 Nostro USD CITIB10NOS­TROUSDnA
Bank BAR­CLAYS BANK, LON­DON BARCB90 BARCGB2A Nostro GBP BARCB90NOS­TROGBPxT

10.12.2 FT Products

Product code Product type
FTNN Internal funds transfer
FTIN Incoming funds transfer
FTOC Outgoing Customer transfer
FTOB Outgoing Bank transfer

10.12.3 BIC codes

Bank Name BIC code
ABN Amro, Frankfurt ABNADEFF
Hambros Bank, London HAMBGB00
Standard Bank, London STDBGB20
ABN Amro, New York ABNAUS33
Chase Manhattan, New York CHASUS33

10.12.4 Settlement Instructions

Assume that the following settlement instructions have been maintained:

Counterparty type CIF ID / BIC Currency Pay account Receive account
BIC HAMBGB00 GBP BARCB90NOSTROGB­PxT BARCB90NOSTROGB­PxT
CIF PSMIT10 GBP PSMIT10INDSB1GB­PaD PSMIT10INDSB1GB­PaD
CIF JBULL10 USD JBULL10INDSB1US­DaD JBULL10INDSB1US­DaD
CIF MIDLB00 GBP MIDLGB00BKCU1GB­PxA MIDLGB00BKCU1GB­PxA

10.12.5 Other maintenance

Example 1: Internal Transfer

Branch code Branch BIC
010 FCBKGB10

In this example, an incoming payment message results in an internal funds transfer i.e. both the debit and credit accounts are serviced by this branch. Thus, the bank here acts as the account with institution.

10.12.6 Incoming Message

Message type: MT 103

Description Tag Contents
Sender 1: MIDLGB2A
Receiver 2: FCBKGB10
Transaction reference num­ber :20: 020615/025/4214
Value date, amount, currency :32A: 020615GBP2000
Ordering customer :50: STEPHEN LEE
Beneficiary customer :59: / PSMIT10INDSB1GB­PaD

 

10.12.7 Interpretation of Message

Debit Account:

Since fields 72, 54 and 53 are absent from the incoming payment message, Oracle FLEXCUBE tries to derive the debit account from the Sender’s BIC.

In this case, the sender is a bank customer and has an account with this branch in the currency of payment.

After successful validation of the customer, account, settlement instructions etc, the debit account is derived as MIDLGB00BKCU1GBPxA.

Credit Account

Since fields 56 and 57 are absent, Oracle FLEXCUBE derives the credit account from Field 59 (Beneficiary customer).

In this case, the account is a valid account for this branch. On successful validation, the credit account is derived as PSMIT10INDSB1GBPaD.

Product

In this case, both parties are customers of the bank, and have accounts in the payment currency. No external party is involved in the transaction, and therefore the transfer is an internal one.

An incoming payment message resulting in an internal transfer has been mapped to product FTNN.

Thus, the contract is created under the product FTNN.

Results

Thus, the following contract results from the incoming MT 103.

Product FTNN
Contract reference num­ber 000FTNN021660152
User reference number 020615/025/4214
Dr currency GBP
Dr amount 2000
Dr branch 010
Dr account MIDLGB00BKCU1GB­PxA
Cr currency GBP
Cr amount 2000
Cr branch 010
Cr account PSMIT10INDSB1GBPaD
Value date 15-JUN-2002

The accounting entries passed would be:

Dr MIDLGB00BKCU1GB­PxA GBP 2000
Cr PSMIT00INDSB1GBPaD GBP 2000

A credit advice will be sent to Peter Smith, and a debit advice to Midland Bank.

10.13 Example 2: Incoming Transfer

In this example, an incoming payment message instructs the bank to receive funds from its USD Nostro agent (Citibank) and to credit the funds to its customer. Thus, the message results in an Incoming funds transfer, with the bank acting as the account with institution.

Incoming Message

Message type: MT 100

Description Tag Contents
Sender 1: ABNADEFF
Receiver 2: FCBKGB10
Transaction reference num­ber :20: 020615/AXT/0009
Value date, amount, currency :32A: 020615USD15000,
Ordering customer :50: STEPHEN LEE
Sender’s correspondent :53A: CITIUS33
Beneficiary customer :59: /JBULL10INDSB1US­DaD

Interpretation of Message

Debit account:

Since fields 72 and 54 are absent from the incoming message, Oracle FLEXCUBE considers field 53A for the derivation of the Debit account.

In this case, the BIC maps on to the USD Nostro for the bank. Oracle FLEXCUBE performs various validations, such as whether the sender (ABN Amro) is authorized to specify this account as the debit account. After successful validations, the debit account is derived as CITIB10NOSTROUSDnA.

Note

Citibank would also send an MT 202 to the bank, confirming that the funds have been re­ceived and credited to the bank’s vostro account.

Credit account:

Since fields 56 and 57 are not present, the credit account is to be derived from field 59. Based on the given account number, the credit account is derived as the USD savings account of John Bull.

Product:

In this case, the ultimate beneficiary’s account belongs to this branch, whereas the debit account is a Nostro. Thus, it is an incoming transfer. Based on the rules maintained, Oracle FLEXCUBE will pick up the relevant Incoming product, and create a new contract.

Results

The following contract results from the above MT 103.

Product FTIN
Contract reference num­ber 000FTIN021660837
User reference number 020615/AXT/0009
Dr currency USD
Dr amount 15000
Dr branch 010
Dr account CITIB10NOS­TROUSDnA
Cr currency USD
Cr amount 15000
Cr branch 010
Cr account JBULL10INDSB1USDaD
Value date 15-JUN-2002

The accounting entries passed are:

Dr CITIB10NOS­TROUSDnA USD 15000
Cr DAO GL USD 15000
Dr DAO GL USD 15000
Cr JBULL10INDSB1USDaD USD 15000

John Bull would receive a credit advice from the bank.

10.14 Example 3: Outgoing Customer Transfer

The incoming payment message in this example instructs the bank to credit funds to the account of Ben Jones with Midland Bank.

Since the ultimate beneficiary is not a bank customer, this results in an outgoing customer transfer. However, since the account with institution has an account with the bank, no cover is required.

Incoming Message

Message type: MT 103

Description Tag Contents
Sender 1: ABNAUS33
Receiver 2: FCBKGB10
Transaction reference num­ber :20: 020630/DE-3275
Bank Instruction Code :23E: SPRI
Value date, amount, currency :32A: 020630GBP4000,
Ordering customer :50K: STEPHEN LEE
Sender’s correspondent :53A: CHASUS33
Receiver’s correspondent :54A: BARCGB2A
Account with institution :57A: MIDLGB2A
Beneficiary customer :59: /BENJONESG­BP2148
Details of charges :71A: OUR

 

Interpretation of Message

10.14.0.1 Debit Account:

In this message, the debit account is derived from field 54. After performing the required validations, this is taken as the nostro account (BARCB90NOSTROGBPxT)

Note

Barclays would also send an MT 202 to the bank, confirming that the funds have been re­ceived and credited to the bank’s vostro account.

Credit Account:

Since field 56 is absent, the Cr account in this case is derived from the BIC in field 57A of the incoming MT 103.

This BIC (MIDLGB2A) has a CIF ID linked to it, and has a valid account in the transfer currency. Thus, the credit account in this case is MIDLGB00BKCU1GBPxA.

Product:

This is an outgoing customer transfer, since the ultimate beneficiary is not a customer of this bank. Based on the rules maintained, the contract will be created under the product FTOC.

Result

The following are the contract details:

Product FTOC
Contract reference num­ber 000FTOC021810006
User reference number 020630/DE-3275
Dr currency GBP
Dr amount 4000
Dr branch 010
Dr account BARCB90NOSTROGB­PxT
Cr currency GBP
Cr amount 4000
Cr branch 010
Cr account MIDLGB00BKCU1GBPxA
Value date 30-JUN-2002

The accounting entries passed are:

Dr BARCB90NOSTROGB­PxT GBP 4000
Cr MIDLGB00BKCU1GBPxA GBP 4000

An MT 103 (customer transfer) is sent to Midland Bank. Since there is a direct accounting relationship between the banks, a cover is not required.

The contents of the outgoing message are shown below:

MT 103 sent to Midland Bank

Description Tag Contents
Sender 1: FCBKGB10
Receiver 2: MIDLGB2A
Transaction reference num­ber :20: 000FTOC021810006
Value date, amount, currency :32A: 020630GBP4000,
Ordering customer :50K: STEPHEN LEE
Beneficiary customer :59: /BENJONESG­BP2148

10.15 Example 4: Outgoing Customer Transfer with Cover

The message below requests the bank to credit funds to Ben Jones’ account with Standard Bank, through Hambros Bank.

The bank therefore sends a payment instruction to Hambros Bank; however, since there is no direct account relationship between the banks, the payment is made through the bank’s GBP Nostro agent, Barclays. A cover payment message is therefore sent to Barclays.

Incoming Message

Message type: MT 103

Description Tag Contents
Sender 1: MIDLGB2A
Receiver 2: FCBKGB10
Transaction reference num­ber :20: 020630/DE-3271
Bank Instruction Code :23E: SPRI
Value date, amount, currency :32A: 020630GBP3821,50
Ordering customer :50K: STEPHEN LEE
Intermediary :56A: HAMBGB00
Account with institution :57A: STDBKGB20
Beneficiary customer :59: /BENJONESG­BP453
Details of charges :71A: OUR

Interpretation of Message

Debit Account

Here, the debit account is derived from the sender’s BIC since fields 55, 72, 54 and 53 are absent. As in the previous example, the debit account is derived as MIDLGB00BKCU1GBPxA.

10.15.0.1 Credit Account

Here, the Cr account is derived from the BIC in field 56 of the incoming MT 103.

The BIC (HAMBGB00) does not have a CIF ID linked to it, since this is not a bank customer. However, since standard settlement instructions have been maintained for this BIC, the credit account is derived from these. In this case, the credit account is maintained as the bank’s GBP nostro i.e. account BARCB90NOSTROGBPxT with Barclays Bank, London.

Thus, the credit account in this case is BARCB90NOSTROGBPxT.

10.15.0.2 Product

This is an outgoing customer transfer. Based on the rules maintained, the contract will be created under the product FTOC.

Result

The following are the contract details:

Product FTOC
Contract reference num­ber 000FTOC021810005
User reference number 020630/DE-3271
Dr currency GBP
Dr amount 3821.50
Dr branch 010
Dr account MIDLGB00BKCU1GBPxA
Cr currency GBP
Cr amount 3821.50
Cr branch 010
Cr account BARCB90NOSTROGB­PxT
Value date 30-JUN-2002

The accounting entries passed are:

Dr MIDLGB00BKCU1GBPxA GBP 3821.50
Cr BARCB90NOSTROGB­PxT GBP 3821.50

The messages sent out are:

  1. An MT 103 (customer transfer) to Hambros Bank, London.
  2. A cover MT 202 (bank transfer) to Barclays Bank, London.

The contents of the outgoing messages are shown below:

MT 103 sent to Hambros Bank
Description Tag Contents
Sender 1: FCBKGB10
Receiver 2: HAMBGB00
Transaction reference num­ber :20: 000FTOC021810005
Value date, amount, currency :32A: 020630GBP3821,50
Ordering customer :50K: STEPHEN LEE
Sender’s correspondent :53A: BARCGB2A
Account with institution :57A: STDBKGB20
Beneficiary customer :59: /BENJONESG­BP453
MT 202 (cover) sent to Barclays
Description Tag Contents
Sender 1: FCBKGB10
Receiver 2: BARCGB2A
Transaction reference num­ber :20: 000FTOC021810005
Related reference number :21: 020630/DE-3271
Value date, amount, currency :32A: 020630GBP3821,50
Account with institution :57A: HAMBGB00
Beneficiary institution :58A: STDBKGB20

10.16 Example 5: Outgoing Bank Transfer

In this example, all the parties to the transfer are banks. The incoming message (MT 202: General Financial Institution Transfer) instructs the bank to credit funds to Hambros Bank.

Since Hambros Bank does not have a direct account relationship with the bank, the payment is routed through Barclays. Thus, the incoming message here results in an Outgoing Bank Transfer, with a cover.

Incoming Message

Message type: MT 202

Description Tag Contents
Sender 1: MIDLGB2A
Receiver 2: FCBKGB10
Transaction reference num­ber :20: 020630/BK-3110
Related reference :21: NONREF
Value date, amount, currency :32A: 020630GBP50000,
Beneficiary institution :58: HAMBGBXX

Interpretation of Message

Debit Account:

In this message, the debit account is derived from the sender BIC. After performing the required validations, this is taken as the customer account (MIDLGB00BKCU1GBPxA)

Credit Account:

Since field 56 and 57 are absent, the Cr account in this case is derived from the BIC in field 58A of the incoming MT 202.

The BIC (HAMBGB00) does not have a CIF ID linked to it, since this is not a bank customer. However, since standard settlement instructions have been maintained for this BIC, the credit account is derived from these. In this case, the credit account is maintained as the bank’s GBP nostro i.e. account BARCB90NOSTROGBPxT with Barclays Bank, London.

Thus, the credit account in this case is BARCB90NOSTROGBPxT.

Product:

This is an outgoing bank transfer, since the ultimate beneficiary institution is not a customer of this bank. Based on the rules maintained, the contract will be created under the product FTOB.

Result

The following are the contract details:

Product FTOC
Contract reference num­ber 000FTOB021815458
User reference number 020630/BK-3110
Dr currency GBP
Dr amount 50000
Dr branch 010
Dr account MIDLGB00BKCU1GBPxA
Cr currency GBP
Cr amount 50000
Cr branch 010
Cr account BARCB90NOSTROGB­PxT
Value date 30-JUN-2002

The accounting entries passed are:

Dr MIDLGB00BKCU1GBPxA GBP 50000
Cr BARCB90NOSTROGB­PxT GBP 50000

An MT 202 is sent to Barclays Bank. The contents of this message are:

MT 202 sent to Barclays Bank
Description Tag Contents
Sender 1: FCBKGB10
Receiver 2: BARCGB2A
Transaction reference num­ber :20: 000FTOB021815458
Related reference :21: 020630/BK-3110
Value date, amount, currency :32A: 020630GBP50000,
Beneficiary institution :58A: HAMBGBXX

10.17 Viewing Funds Transfer Multi Customer Summary

You can generate a consolidated message for all the funds transfer transactions grouped under a consolidated reference maintained in the system using ‘Funds Transfer Multi Customer‘ screen. You can invoke the ‘Funds Transfer Multi Customer Summary’ screen by typing ‘FTSTCONS’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Here you can query on records based on the following criteria: