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:
This chapter contains the following sections:
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.
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.
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 unauthorized) defined for the source from which it is uploaded.
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:
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.
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.
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:
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 |
Parties |
ACC (Info for Acc with Inst) |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
2 |
Parties |
INS (Instructing Inst) |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
3 |
Parties |
RCB (Receiver’s Correspondent) |
Try and Derive the Debit Account from contents specified 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 Applicable |
Not Applicable |
Not Applicable |
4 |
Parties |
INT (Info for Intermediary) |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
5 |
Parties |
REC (Info for Receiver of Payment) |
Not Applicable |
Mark Incoming SWIFT Payment Message for Repair with an appropriate repair reason. |
Mark Incoming SWIFT Payment Message for Repair with an appropriate repair reason. |
Mark Incoming SWIFT Payment Message for Repair with an appropriate repair reason. |
6 |
Parties |
BNF (Info for Beneficiary) |
Not Applicable |
Not Applicable |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
7 |
Method of Payment |
BENONLY (Payment for Ben only) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Not Applicable |
Not Applicable |
8 |
Method of Payment |
CHEQUE (Payment by cheque only) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Not Applicable |
Not Applicable |
9 |
Method of Payment |
CORPTRAD (FX Settlement) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Not Applicable |
Not Applicable |
10 |
Method of Payment |
HOLD (Pay upon customer ID) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Not Applicable |
Not Applicable |
11 |
Method of Payment |
INTRACOM |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Not Applicable |
Not Applicable |
12 |
Method of Advice |
PHON (Advise Acc with Inst by phone) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
13 |
Method of Advice |
PHONBEN (Advise Ben by phone) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
14 |
Method of Advice |
PHONIBK (Advise Intermediary by phone) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
15 |
Method of Advice |
TELE (Advise Acc with Inst) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
16 |
Method of Advice |
TELEBEN (Advise Ben) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
17 |
Method of Advice |
TELEIBK (Advise Intermediary) |
Copy to field 72 of Payment Transaction being created. |
Not Applicable |
Copy to field 72 of Payment Transaction being created. |
Copy to field 72 of Payment Transaction being created. |
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 Incoming SWIFT Message for Repair with appropriate repair reason. |
Mark Incoming SWIFT Message for Repair with appropriate repair reason. |
Not Applicable |
Parties |
INS (Instructing Inst) |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Parties |
RCB (Receiver’s Correspondent) |
Try and Derive the Debit Account from contents specified 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 else mark SWIFT Message for Repair. |
Not Applicable |
Not Applicable |
Not Applicable |
Parties |
INT (Info for Intermediary) |
Not Applicable |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Parties |
REC (Info for Receiver of Payment) |
Not Applicable |
Mark Incoming 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 Applicable |
Parties |
BNF (Info for Beneficiary) |
Not Applicable |
Not Applicable |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Method of Payment |
BENONLY (Payment for Ben only) |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Not Applicable |
Not Applicable |
Method of Payment |
CHEQUE (Payment by cheque only) |
Mark Incoming SWIFT Message for Repair with appropriate repair reason. |
Not Applicable |
Not Applicable |
Not Applicable |
Method of Payment |
CORPTRAD (FX Settlement) |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Not Applicable |
Not Applicable |
Method of Payment |
HOLD (Pay upon customer ID) |
Mark Incoming SWIFT Message for Repair with appropriate repair reason. |
Not Applicable |
Not Applicable |
Not Applicable |
Method of Payment |
INTRACOM |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Not Applicable |
Not Applicable |
Method of Advice |
PHON (Advise Acc with Inst by phone) |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Method of Advice |
PHONBEN (Advise Ben by phone) |
Mark Incoming SWIFT Message for Repair with appropriate repair reason. |
Not Applicable |
Mark Incoming SWIFT Message for Repair with appropriate repair reason. |
Not Applicable |
Method of Advice |
PHONIBK (Advise Intermediary by phone) |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Method of Advice |
TELE (Advise Acc with Inst) |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Method of Advice |
TELEBEN (Advise Ben) |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Method of Advice |
TELEIBK (Advise Intermediary) |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
Copy to field 72 of Payment Transaction being created & process Incoming SWIFT Message. |
Not Applicable |
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.
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.
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.
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:
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.
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 example, 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.
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 entry (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.
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.
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 processing 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.
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.
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.
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:
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:
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.
Oracle FLEXCUBE provides a facility to processes incoming Credit Card payments through SWIFT message. The system processes these FT messages as follows:
This section contains the following topics:
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.
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.
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.
Oracle FLEXCUBE STP process will automatically generate an Outgoing Payment Cover Message (MT 202) if the following criteria are satisfied:
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.
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.
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:
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.
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.
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.
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 already been processed by the system.
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.
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.
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.
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 Payment Message received from the SWIFT network.
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 message |
Post correction message goes through the STP process again. |
|
|
Suppress the entire message |
The entire message is suppressed and no further action is taken on the message |
|
|
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 Exception |
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 Authorization |
No |
Authorize the transaction |
|
Failed Authorization |
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:
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.
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:
Assume that the following maintenance has been done in the system.
Customer type |
Customer Name |
CIF ID |
BIC |
Account Type |
Account Ccy |
Account ID |
Bank |
MIDLAND BANK |
MIDLB00 |
MIDLGB2A |
Current |
GBP |
MIDLGB00BKCU1GBPxA |
Individual |
PETER SMITH |
PSMIT10 |
|
Savings |
GBP |
PSMIT10INDSB1GBPaD |
Individual |
JOHN BULL |
JBULL10 |
|
Savings |
USD |
JBULL10INDSB1USDaD |
Bank |
CITIBANK |
CITIB10 |
CITIUS33 |
Nostro |
USD |
CITIB10NOSTROUSDnA |
Bank |
BARCLAYS BANK, LONDON |
BARCB90 |
BARCGB2A |
Nostro |
GBP |
BARCB90NOSTROGBPxT |
Product code |
Product type |
FTNN |
Internal funds transfer |
FTIN |
Incoming funds transfer |
FTOC |
Outgoing Customer transfer |
FTOB |
Outgoing Bank transfer |
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 |
Assume that the following settlement instructions have been maintained:
CIF ID / BIC |
Currency |
Pay account |
Receive account |
|
BIC |
HAMBGB00 |
GBP |
BARCB90NOSTROGBPxT |
BARCB90NOSTROGBPxT |
CIF |
PSMIT10 |
GBP |
PSMIT10INDSB1GBPaD |
PSMIT10INDSB1GBPaD |
CIF |
JBULL10 |
USD |
JBULL10INDSB1USDaD |
JBULL10INDSB1USDaD |
CIF |
MIDLB00 |
GBP |
MIDLGB00BKCU1GBPxA |
MIDLGB00BKCU1GBPxA |
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.
Message type: MT 103
Description |
Tag |
Contents |
Sender |
1: |
MIDLGB2A |
Receiver |
2: |
FCBKGB10 |
Transaction reference number |
:20: |
020615/025/4214 |
Value date, amount, currency |
:32A: |
020615GBP2000 |
Ordering customer |
:50: |
STEPHEN LEE |
Beneficiary customer |
:59: |
/ PSMIT10INDSB1GBPaD |
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.
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.
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.
Thus, the following contract results from the incoming MT 103.
Product |
FTNN |
Contract reference number |
000FTNN021660152 |
User reference number |
020615/025/4214 |
Dr currency |
GBP |
Dr amount |
2000 |
Dr branch |
010 |
Dr account |
MIDLGB00BKCU1GBPxA |
Cr currency |
GBP |
Cr amount |
2000 |
Cr branch |
010 |
Cr account |
PSMIT10INDSB1GBPaD |
Value date |
15-JUN-2002 |
The accounting entries passed would be:
Dr |
MIDLGB00BKCU1GBPxA |
GBP |
2000 |
Cr |
PSMIT00INDSB1GBPaD |
GBP |
2000 |
A credit advice will be sent to Peter Smith, and a debit advice to Midland Bank.
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.
Message type: MT 100
Description |
Tag |
Contents |
Sender |
1: |
ABNADEFF |
Receiver |
2: |
FCBKGB10 |
Transaction reference number |
:20: |
020615/AXT/0009 |
Value date, amount, currency |
:32A: |
020615USD15000, |
Ordering customer |
:50: |
STEPHEN LEE |
Sender’s correspondent |
:53A: |
CITIUS33 |
Beneficiary customer |
:59: |
/JBULL10INDSB1USDaD |
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 received and credited to the bank’s vostro 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.
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.
The following contract results from the above MT 103.
Product |
FTIN |
Contract reference number |
000FTIN021660837 |
User reference number |
020615/AXT/0009 |
Dr currency |
USD |
Dr amount |
15000 |
Dr branch |
010 |
Dr account |
CITIB10NOSTROUSDnA |
Cr currency |
USD |
Cr amount |
15000 |
Cr branch |
010 |
Cr account |
JBULL10INDSB1USDaD |
Value date |
15-JUN-2002 |
The accounting entries passed are:
Dr |
CITIB10NOSTROUSDnA |
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.
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.
Message type: MT 103
Description |
Tag |
Contents |
Sender |
1: |
ABNAUS33 |
Receiver |
2: |
FCBKGB10 |
Transaction reference number |
: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: |
/BENJONESGBP2148 |
Details of charges |
:71A: |
OUR |
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 received and credited to the bank’s vostro 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.
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.
The following are the contract details:
Product |
FTOC |
Contract reference number |
000FTOC021810006 |
User reference number |
020630/DE-3275 |
Dr currency |
GBP |
Dr amount |
4000 |
Dr branch |
010 |
Dr account |
BARCB90NOSTROGBPxT |
Cr currency |
GBP |
Cr amount |
4000 |
Cr branch |
010 |
Cr account |
MIDLGB00BKCU1GBPxA |
Value date |
30-JUN-2002 |
The accounting entries passed are:
Dr |
BARCB90NOSTROGBPxT |
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 number |
:20: |
000FTOC021810006 |
Value date, amount, currency |
:32A: |
020630GBP4000, |
Ordering customer |
:50K: |
STEPHEN LEE |
Beneficiary customer |
:59: |
/BENJONESGBP2148 |
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.
Message type: MT 103
Description |
Tag |
Contents |
Sender |
1: |
MIDLGB2A |
Receiver |
2: |
FCBKGB10 |
Transaction reference number |
: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: |
/BENJONESGBP453 |
Details of charges |
:71A: |
OUR |
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.
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.
This is an outgoing customer transfer. Based on the rules maintained, the contract will be created under the product FTOC.
The following are the contract details:
Product |
FTOC |
Contract reference number |
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 |
BARCB90NOSTROGBPxT |
Value date |
30-JUN-2002 |
The accounting entries passed are:
Dr |
MIDLGB00BKCU1GBPxA |
GBP |
3821.50 |
Cr |
BARCB90NOSTROGBPxT |
GBP |
3821.50 |
The messages sent out are:
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 number |
: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: |
/BENJONESGBP453 |
MT 202 (cover) sent to Barclays |
||
Description |
Tag |
Contents |
Sender |
1: |
FCBKGB10 |
Receiver |
2: |
BARCGB2A |
Transaction reference number |
: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 |
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.
Message type: MT 202
Description |
Tag |
Contents |
Sender |
1: |
MIDLGB2A |
Receiver |
2: |
FCBKGB10 |
Transaction reference number |
:20: |
020630/BK-3110 |
Related reference |
:21: |
NONREF |
Value date, amount, currency |
:32A: |
020630GBP50000, |
Beneficiary institution |
:58: |
HAMBGBXX |
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)
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.
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.
The following are the contract details:
Product |
FTOC |
Contract reference number |
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 |
BARCB90NOSTROGBPxT |
Value date |
30-JUN-2002 |
The accounting entries passed are:
Dr |
MIDLGB00BKCU1GBPxA |
GBP |
50000 |
Cr |
BARCB90NOSTROGBPxT |
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 number |
:20: |
000FTOB021815458 |
Related reference |
:21: |
020630/BK-3110 |
Value date, amount, currency |
:32A: |
020630GBP50000, |
Beneficiary institution |
:58A: |
HAMBGBXX |
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: