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: