Business Guide GPP Message Types
User Manual: Pdf
Open the PDF directly: View PDF .
Page Count: 54
Download | |
Open PDF In Browser | View PDF |
Global PAYplus Message Types Business Guide Product Version: 4.6.8 Catalog ID: GPP4.6-00-B49-03-201709 Copyright © 2009 - 2018 Finastra International Limited, or a member of the Finastra group of companies (“Finastra”). All Rights Reserved. Confidential - Limited Distribution to Authorized Persons Only, pursuant to the terms of the license agreement by which you were granted a license from Finastra for the applicable software or services and this documentation. Republication or redistribution, in whole or in part, of the content of this documentation or a ny other materials made available by Finastra is prohibited without the prior written consent of Finastra. The software and documentation are protected as unpublished work and constitute a trade secret of Finastra International Limited, or a member of the Finastra group of companies, Head Office: One Kingdom Street, Paddington, London W2 6BL, United Kingdom. Disclaimer Finastra does not guarantee that any information contained herein is and will remain accurate or that use of the information will ensure correct and faultless operation of the relevant software, services or equipment. This document contains information proprietary to Finastra. Finastra does not undertake mathematical research but only applies mathematical models recognized within the financial industry. Finastra does not guarantee the intrinsic theoretical validity of the calculation models used. Finastra, its agents, and employees shall not be held liable to or through any user for any loss or damage whatsoever resulting from reliance on the information contained herein or related thereto. The information contained in this document and the general guidance of Finastra staff does not take the place of qualified compliance personnel or legal counsel within your institution. FINASTRA CANNOT RENDER LEGAL, ACCOUNTING OR OTHER PROFESSIONAL SERVICES TO YOUR INSTITUTION. THE INFORMATION CONTAINED HEREIN IS GENERAL IN NATURE AND DOES NOT CONSTITUTE LEGAL ADVICE OR A LEGAL OPINION. CONSULT YOUR LEGAL COUNSEL FOR LEGAL ADVICE SPECIFIC TO YOUR SITUATION OR CIRCUMSTANCES OR TO ANSWER ANY LEGAL QUESTIONS. This document is not intended as a substitute for formal education in the regulatory requirements of banking, banking operations, lending, lending operations, or other topics generally applicable to financial institutions. Your financial institution is solely responsible for configuring and using the software or services in a way that meets policies, practices, and laws applicable to your institution, including, without limitation: (1) options and selectio ns made on prompts; (2) entries in the software program; (3) program setup; and (4) documents produced by the software or services. It is the obligation of the customer to ensure that responsible decisions are taken when using Finastra products. Information in this document is subject to change without notice and does not represent a commitment on the part of Finastra. Feedback Do you have comments about our guides and online help? Please address any comments and questions to your local Finastra representative. Need more information? Read more about our products at http://www.finastra.com or contact your local Finastra office at http://www.finastra.com/contact. Version Control Version Date 1.0 Summary of Changes Document Created 2.0 Mar 2016 Added MT102, MT203, and MT204 3.0 April 2017 Added new section for ISO 2022 Processing, camt.054 Global PAYplus | Message Types | Business Guide Page 3 Table of Contents 1 INTRODUCTION .................................................................................................................... 5 1.1 1.2 1.3 1.4 2 Overview .......................................................................................................................... 5 SWIFT Messages............................................................................................................. 6 ISO 20022 Message Standards ........................................................................................ 8 Target Audience............................................................................................................... 8 SWIFT PROCESSING ............................................................................................................ 8 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 3 MT101 Message .............................................................................................................. 8 Overview ...................................................................................................................... 9 Processing.................................................................................................................. 10 Manual Handling......................................................................................................... 17 Business Setup........................................................................................................... 17 Message Data ............................................................................................................ 18 MT102 Message ............................................................................................................ 19 Overview .................................................................................................................... 19 Processing.................................................................................................................. 20 Manual Handling......................................................................................................... 25 Business Setup........................................................................................................... 25 Message Data ............................................................................................................ 27 MT203 Message ............................................................................................................ 28 Overview .................................................................................................................... 28 Processing.................................................................................................................. 29 Manual Handling......................................................................................................... 31 Business Setup........................................................................................................... 32 Message Data ............................................................................................................ 32 MT204 Message ............................................................................................................ 32 Overview .................................................................................................................... 32 Processing.................................................................................................................. 33 Manual Handling......................................................................................................... 36 Business Setup........................................................................................................... 36 Message Data ............................................................................................................ 36 MT210 Message ............................................................................................................ 37 Overview .................................................................................................................... 37 Processing.................................................................................................................. 37 Manual Handling......................................................................................................... 38 Business Setup........................................................................................................... 38 Message Data ............................................................................................................ 50 ISO 2022 PROCESSING ...................................................................................................... 52 3.1 camt.054 Message ......................................................................................................... 52 APPENDIX A: GLOSSARY ............................................................................................................. 54 Global PAYplus | Message Types | Business Guide Page 4 1 Introduction 1.1 Overview This document describes the Global PAYplus (GPP) supported functionality for processing messages within GPP. SWIFT: The Society for Worldwide Interbank Financial Telecommunication is a member-owned cooperative through which the financial world conducts its business operations. More than 10,000 banking organizations, securities institutions and corporate customers in 212 countries exchange millions of standardized financial messages. - For a list of message types supported in GPP - For message types processing, see SWIFT Processing ISO 20022 Message Standards: ISO20022 is a universal financial industry message scheme. - For a list of message types supported in GPP, see Global PAYplus | Message Types | Business Guide Page 5 - ISO 20022 Message Standards. FED: Fedwire Funds Transfer payments. For a list of message types and processing, see GPP Business Guide FedWire. CHIPS: The Clearing House Interbank Payments System (CHIPS) is a United States private clearing house for large-value transactions. For a list of message types and processing, see GPP Business Guide CHIPS. Posting Logic: For information on GPP-supported Accounting models, a description of configurations, and more details about Posting logic manual handling, see GPP Business Guide Posting. 1.2 SWIFT Messages These are the SWIFT messages that are supported by GPP: Message Type Message Sub Type Description Reference SWIFT_103 PLS Single customer credit transfer For format and rules refer to SWIFT Book/Category 1/MT103 SWIFT_103 Single customer credit transfer. The PLS refer to payment STP For format and rules refer to SWIFT Book/Category 1/MT103 SWIFT_190 Advice of charges For format and rules refer to SWIFT Book/Category 1/MT190 SWIFT_191 Request for charges For format and rules refer to SWIFT Book/Category 1/MT191 SWIFT_192 Request for cancellation For format and rules refer to SWIFT Book/Category 1/MT192 SWIFT_195 Queries SWIFT_196 Answers SWIFT_198 550 SWIFT_198 557 Proprietary message SWIFT_198 SWIFT_199 Free format message SWIFT_200 Financial institution transfer for For format and rules refer to each own account SWIFT Book/Category 2/MT200 SWIFT_202 202 cover - General Financial Institution Transfer For format and rules refer to SWIFT Book/Category 2/MT202 SWIFT_202 General Financial Institution Transfer For format and rules refer to SWIFT Book/Category 2/MT202 SWIFT_205 Financial institution transfer execution For format and rules refer to SWIFT Book/Category 2/MT205 SWIFT_210 COV RVR Notice to receive Global PAYplus | Message Types | Business Guide Page 6 Message Type Message Sub Type Description Reference SWIFT_210 SWIFT_290 Advice of charges SWIFT_291 Request for payment cancellation SWIFT_292 SWIFT_295 SWIFT_296 SWIFT_298 550 SWIFT_298 557 SWIFT_298 SWIFT_298_011 SWIFT_298_012 SWIFT_298_013 RVR SWIFT_298_013 SWIFT_298_014 SWIFT_299 Free format SWIFT_400 Advice of payment SWIFT_900 Debit confirmation SWIFT_910 950 For format and rules refer to SWIFT Book/Category 4/MT400 Credit confirmation SWIFT_910 SWIFT_940 Customer statement message SWIFT_941 Balance report SWIFT_942 Interim transaction report SWIFT_950 Statement message Global PAYplus | Message Types | Business Guide Page 7 1.3 ISO 20022 Message Standards These are the ISO20022 messages that are supported by GPP. Message Type ISO MT Version Description ACMT_023 acmt.023.001.01 Account management CAMT_052 camt.052.001.02 Bank to customer account report CAMT_053 camt.053.001.02 Bank to customer statement CAMT_054 camt.054.001.02 camt.054.001.03 camt.054.001.04 Bank to customer debit credit notification CAMT_029 camt.029.001.03 Resolution of investigation CAMT_056 camt.056.001.01 FI (financial institution) to FI payment cancellation request PACS_002 pacs.002.001.03 FI to FI payment status report PACS_003 pacs.003.001.02 FI to FI customer direct debit PACS_004 pacs.004.001.02 pacs.004.001.03 Payment return PACS_007 pacs.007.001.02 FI to FI payment reversal PACS_008 pacs.008.001.02 FI to FI customer credit transfer PACS_009 pacs.009.001.02 pacs.009.001.03 PAIN_001 pain.001.001.02 pain.001.001.03 Customer credit transfer initiation PAIN_002 pain.002.001.02 pain.002.001.03 Customer payment status report PAIN_007 pain.007.001.02 Customer payment reversal PAIN_008 pain.008.001.02 Customer direct debit initiation 1.4 Target Audience This business guide is designed for business analysts and system administrators who need to set up and configure the Message Types feature. It is also of value to anyone who wants to know more about how this feature is implemented. This document assumes that the reader is familiar with basic GPP and financial technology terms and definitions. 2 SWIFT Processing 2.1 MT101 Message This section describes the processing of MT101 messages received from SWIFT in GPP. The MT101 messages received from SWIFT are de-bulked into individual MT103 child messages. These child messages either end in GPP as BOOK transfers or are processed via RTGS/SWIFT MOPS as required. Global PAYplus | Message Types | Business Guide Page 8 Note: The MT101 message type does not require prior Message User Group (MUG) registration. A Message User Group (MUG) is a group of users who have voluntarily agreed to support the specified message type and have registered with SWIFT to send or receive the specified message type. For more information, see SWIFT Message Types in the SWIFT User Handbook. 2.1.1 Overview An MT101 SWIFT message is sent by a financial institution on behalf of a non-financial institution account owner (the ordering customer or instructing party). It is subsequently received by the receiving financial institution and processed by the receiving financial institution or the account servicing the financial institution. The MT101 is used to move funds from the ordering customer's account(s) which are serviced: At the receiving financial institution At the account servicing institution From an account(s) owned by the ordering customer for which the instructing customer has explicit authority to debit, such as a subsidiary account MT101 messages can be processed as Incoming SWIFT messages, ending on the bank’s books only. The child messages can either be settled on the bank’s books or sent out through standard, applicable MOPs. 2.1.1.1 MT101 Terminology This is a list of the terms and abbreviations used in this document. Refer to Appendix A: Glossary Error! Reference source not found.for additional terms and their definitions: Term Description Incoming MT101 messages received from another financial institution, where the debit customer’s account (Field 50H) and the credit account (Field 59) are held on the Local Office’s books. The child messages are terminated as BOOK payments. Onward MT101 messages received from another financial institution, where the debit customer (Field 50H) holds an account with the Local Office and the credit party (Field 59) holds an account at another FI (Field 57). The child messages are sent out to the next FI in the Credit Chain. Parent message The Bulked message MT101. Child message The de-bulked individual payment message of MT101 (each child of an MT101 is a single MT103) 2.1.1.2 MT101 Sequences The MT101 consists of these sequences: Sequence Name Description A General Description A single occurrence sequence which contains information that applies to all individual transactions as described in Sequence B. B Transaction Details A repetitive sequence in which each occurrence provides details of one individual transaction. Fields which appear in both sequences are mutually exclusive. Global PAYplus | Message Types | Business Guide Page 9 2.1.2 Processing 2.1.2.1 Incoming MT101 Process The process flow for incoming MT101 messages is as follows: 1. GPP receives an incoming MT101 from another FI. - GPP stores the MT101 message in the MINF table in the database with basic level mapping. For a list of fields, see The incoming MT101 is stored in a new PDO with limited mapping before spawning the MT103 messages based on Sequence B. - GPP populates Field 21F (if exists) of the MT101 into the Xchgrate ctrct field and subsequently copies it into the Contract field of the MESSAGERATES table. - When an MT101 is received, these fields are mapped in GPP: No SWIFT Tag & Field Logical ID Field Name Alias GPP DB Comments Table 1. NA P_MID MID MINF 2. NA XML_ORIG_MSG NA MINF 3. NA P_OFFICE Pmt office MINF 4. NA P_DEPARTMENT Department MINF Set using Business rule 5. NA P_MSG_TYPE Msg tp MINF SWIFT_101 6. NA P_MSG_STS Msg sts MINF 7. NA P_BA_CD Business area cd MINF Set using Business rule 8. NA P_PRODUCT_CD Product cd MINF Set using Business rule 9. NA P_MSG_CLASS Msg class MINF NAC 10. NA P_ORIG_MSG_TYP Orgnl msg tp E MINF SWIFT_101 11. NA P_DISPLAY_MSG_T Display Msg tp YPE MINF 101 12. NA P_DBT_MOP Dbt MOP MINF SWIFT 13. Tag 20:Sender’s Reference P_INSTR_ID Instr ID MINF 14. Tag 20:Sender’s Reference P_ORIG_INSTR_ID Original Instr ID MINF 15. Orig Sender BIC in Block 2 OX_INSTG_AGT_BI Orgnl Instg agt C_2AND BIC 2 Global PAYplus | Message Types | Business Guide System generated XML_OR IG_MSG Page 10 No SWIFT Tag & Field Logical ID Field Name 16. Orig Receiver OX_INSTD_AGT_BI Orgnl instd agt BIC 2 BIC in Block C_2AND 1 2.1.2.2 Alias GPP DB Comments Table XML_OR IG_MSG Mapping Incoming MT101 to Child MT103 Notes: According to the SWIFT book, Fields 20, 21R, 28D, 51A, 25, 21F and 25A should not be mapped onto the MT103. However, since Field 20 is mandatory in MT103 and also mandatory for GPP processing, it is mapped in GPP. This table shows the mapping of the Original Incoming messages to the applicable child MT103 messages. Original Incoming MT101 Message 20 21R 28D 50a (C or L) 50a (F, G, or H) - Either in Sequence A or Sequence B 52a (A or C) 51A 30 25 21 21F 23E 32B 56a (A, C, or D) 57a (A, C, or D) 59a (No letter option or A) 70 77B 33B 71A 25A Global PAYplus | Message Types | Business Guide Page 11 Original Incoming MT101 Message 36 Child MT103 Not mapped onto MT103 Not mapped onto MT103 Not mapped onto MT103 If both Field 50a Instructing Party (50C or L) and Field 50a Ordering Customer (50F, G or H) are present in the MT101 then, per default, Field 50a Ordering Customer is mapped onto the subsequent MT103. 50a (A, F or K) 52a Not mapped onto MT103 32A (subfield 1) Note: Field 30 of the MT101 is used to construct subfield 1 of Field 32A of the MT103. N/A 20 Note: according to SWIFT book It is not mandatory to map Field 21 of the MT 101 in the MT103. However, if required, it should be mapped onto Field 70 of the MT103 as follows: :70:/ROC/value Stored in Orgnl xchgrate ctrct field. For more information, see Mapping of Field 21F of MT101. 23E 32A Receiver 57a (A, C, or D) 59a (No letter option or A) 70 77B 33B When present, Field 33B of the MT101 is mapped onto Field 33B of the MT103. If Field 33B is not present in the MT101, Field 32B of the MT101 is mapped onto Field 33B of the MT103. Global PAYplus | Message Types | Business Guide Page 12 Child MT103 In all other cases, Field 32B of the MT101 is used to build subfields 2 and 3 of Field 32A of the MT103 (see Field 32B). 71A Stored in the OX_FEE_ACCT_NB/X_FEE_ACCT_NB. For more information, see Mapping of Field 25 of MT101. 36 - The MT101 message can be viewed in the Before/After tab of the MT101 message. For each payment, GPP displays in the Before tab the new 101/103 message sub type and in the After tab the MT103 child). 2. GPP generates the MID for the MT101, which is then is parsed and mapped into the database. 3. GPP invokes the enrichment, product and department rules on MT101. 4. GPP performs a duplication check on the MT101 message. 5. GPP invokes the Set Basic properties service on the MT101, which sets the MID, Dbt MOP and Pmt Office for the message. Subsequently, rules are invoked to evaluate the Payment attributes Department, Business Area and the Product code for the MT101 message. - - If GPP fails to derive these attributes: › The message is routed to the Repair queue with a relevant error code. › The message class of the MT101 is set as NAC (non-accounting message class, such as that used for non-debit lump sum mode). If successful, GPP continues to process the message. 6. GPP generates the Local Reference for MT101. 7. GPP de-bulks the MT101 message, spawns the child MT103 messages and moves the MT101 to the Complete queue. The child MT103 messages are linked to the Orig MT101 in MFAMILY. A user can view the message from the Links tab in the GPP user interface. For more information, see De-bulking MT101 to MT103s. 8. GPP then starts processing the individual MT103 child messages. 9. During debit side processing, GPP checks whether the sender’s BIC has debit authority for the account specified in Field 50H. - When a Debit Authorization profile does not exist, a relevant error message is recorded and the MT103 is routed to Repair queue. - If an F50H account is identified as an invalid account in GPP, MT101 processes STP to Complete queue, while child MT103s are routed to Repair queue. 10. The individual MT103 message continues to process per standard high value processing of MT103 messages (for example, Cr side identification, MOP selection/validation, balance checks, fees, accounting). 2.1.2.3 De-bulking MT101 to MT103s Once the MT101 is stored in MINF and the basic processing of the message is completed, GPP spawns multiple MT103 messages (child messages based on Sequence A and B) from the MT101 (parent message) and sends the parent message to Complete. The message class of the MT101 parent message is set as NAC. The Orig message type (Logical field P_ORIG_MSG_TYPE) for the MT103 is set as SWIFT_101. The parent MT101 and child MT103s are linked in MFAMILY. Global PAYplus | Message Types | Business Guide Page 13 2.1.2.4 De-bulking Parent Messages The child messages (single instance of a MT101) are assigned with a new message sub type 103 in SWIFT Tag 119 of the Block 3. The message type remain MT101. GPP generates the child message as follows: Original message of the child is inherited from the MT101, containing the entire Sequence A and the entire respective Sequence B (copy as is). GPP sends the message back into the queue for processing. For each payment GPP displays in the Before tab the respective new MT101/MT103 message type and in the After tab the MT103 child. GPP generates the MT103 child message as follows: Outgoing Message of the child (MT103) is formatted as per standard SWIFT guidelines. The MT101 and the child MT103 remain linked. MT103 is processed as in the standard high value process. For mapping details, see Mapping Incoming MT101 to Child MT103. 2.1.2.5 Mapping The MT101 mapping process has two different goals: - De-bulking the messages to separate messages - Mapping the fields from SWIFT format to GPP format For each MT101, GPP creates one bulked message record in MINF database table, and the same number of un-bulked message records, as of Sequence B repetitions. Sequences A and B are mapped to every child message. It is not necessary to have bulk payments for MT101. That means that an MT101 can have single or multiple occurrences of payment instructions. Multiple payment instruction have multiple occurrence of Sequence B while single payment instruction has just one occurrence of Sequence B. 2.1.2.6 Mapping Incoming MT101 to GPP DB The incoming MT101 is stored in a new PDO with limited mapping before spawning the MT103 messages based on Sequence B. GPP populates Field 21F (if exists) of the MT101 into the Xchgrate ctrct field and subsequently copies it into the Contract field of the MESSAGERATES table. When an MT101 is received, these fields are mapped in GPP: No SWIFT Tag & Field Name Field Logical ID Alias GPP DB Table Comments 17. NA P_MID MID MINF System generated 18. NA XML_ORIG_MSG NA MINF 19. NA P_OFFICE Pmt office MINF 20. NA P_DEPARTMENT Department MINF Set using Business rule 21. NA P_MSG_TYPE Msg tp MINF SWIFT_101 22. NA P_MSG_STS Msg sts MINF Global PAYplus | Message Types | Business Guide Page 14 No SWIFT Tag & Field Name Field Logical ID Alias GPP DB Table Comments 23. NA P_BA_CD Business area cd MINF Set using Business rule 24. NA P_PRODUCT_CD Product cd MINF Set using Business rule 25. NA P_MSG_CLASS Msg class MINF NAC 26. NA P_ORIG_MSG_TYPE Orgnl msg tp MINF SWIFT_101 27. NA P_DISPLAY_MSG_TYP Display Msg tp E MINF 101 28. NA P_DBT_MOP Dbt MOP MINF SWIFT 29. Tag 20:Sender’s Reference P_INSTR_ID Instr ID MINF 30. Tag 20:Sender’s Reference P_ORIG_INSTR_ID Original Instr ID MINF 31. Orig Sender BIC in Block 2 OX_INSTG_AGT_BIC_ Orgnl Instg agt 2AND BIC 2 XML_ORI G_MSG 32. Orig Receiver BIC in Block 1 OX_INSTD_AGT_BIC_ Orgnl instd agt 2AND BIC 2 XML_ORI G_MSG 2.1.2.7 Mapping Incoming MT101 to Child MT103 Notes: According to the SWIFT book, Fields 20, 21R, 28D, 51A, 25, 21F and 25A should not be mapped onto the MT103. However, since Field 20 is mandatory in MT103 and also mandatory for GPP processing, it is mapped in GPP. This table shows the mapping of the Original Incoming messages to the applicable child MT103 messages. Original Incoming MT101 Message Child MT103 20 Not mapped onto MT103 21R Not mapped onto MT103 28D Not mapped onto MT103 50a (C or L) If both Field 50a Instructing Party (50C or L) and Field 50a Ordering Customer (50F, G or H) are present in the MT101 then, per default, Field 50a Ordering Customer is mapped onto the subsequent MT103. 50a (F, G, or H) - Either in Sequence A or Sequence B 50a (A, F or K) 52a (A or C) 52a 51A Not mapped onto MT103 Global PAYplus | Message Types | Business Guide Page 15 Original Incoming MT101 Message Child MT103 30 32A (subfield 1) Note: Field 30 of the MT101 is used to construct subfield 1 of Field 32A of the MT103. 25 N/A 21 20 Note: according to SWIFT book It is not mandatory to map Field 21 of the MT 101 in the MT103. However, if required, it should be mapped onto Field 70 of the MT103 as follows: :70:/ROC/value 21F Stored in Orgnl xchgrate ctrct field. For more information, see Mapping of Field 21F of MT101. 23E 23E 32B 32A 56a (A, C, or D) Receiver 57a (A, C, or D) 57a (A, C, or D) 59a (No letter option or A) 59a (No letter option or A) 70 70 77B 77B 33B 33B When present, Field 33B of the MT101 is mapped onto Field 33B of the MT103. If Field 33B is not present in the MT101, Field 32B of the MT101 is mapped onto Field 33B of the MT103. In all other cases, Field 32B of the MT101 is used to build subfields 2 and 3 of Field 32A of the MT103 (see Field 32B). 71A 71A 25A Stored in the OX_FEE_ACCT_NB/X_FEE_ACCT_NB. For more information, see Mapping of Field 25 of MT101. 36 36 2.1.2.8 Mapping of Field 21F of MT101 When an MT101 is received, it is de-bulked into individual MT103 messages based on Sequence A and B. Field 21F of Sequence B of each MT101 is stored in Xchgrate ctrct field (Logical fieldX_XCHGRATEINF_CTRCTID) for each newly spawned MT103. This enables GPP to provide the FX contract information to the Financial Institution FX engine for validation at the time of FX processing. A new entry is added to MESSAGERATES table with all mandatory data derived from the payment. The value in Xchgrate ctrct field is then copied into the Contract field of the MESSAGERATES table in the database. Global PAYplus | Message Types | Business Guide Page 16 2.1.2.9 Mapping of Field 25 of MT101 When an MT101 is received with Field 25 quoting fee account number, it is copied to logical fields OX_FEE_ACCT_NB and X_FEE_ACCT_NB. The Repair & Enrichment system rule is added to the map fee account as provided in the MT101 to the processing fee account number P_DBT_FEE_ACCT_NB. The expectation is that the P_DBT_FEE_ACCT_NB is sent to the external Financial Institution’s system in the Account lookup request call and the account’s supplementary information is returned as part of the account lookup response as account number, currency, office to uniquely identify the relevant fee account as defined in GPP. The Account lookup response handler uses this information to load the details of the relevant fee account by the provided account number, currency, and office key. From this point, GPP uses this fee account for further payment processing, with the assumption is that the fee account is defined in the GPP. 2.1.3 Manual Handling 2.1.3.1 View Messages A GPP user can view the following messages in the Message page: Linked messages: From Links tab of the MT101, the user can view the MT103 message, from any GPP status. Similarly, the user can also view the MT101 message from the Links tab of the MT103. Orig MT101 message: Available from Before/After tab 2.1.3.2 Message Actions Note: When a button is marked as Button Dual Control Required, it is also required to define the Dual Control (159) and Message workflow determination – Manual (125) rules, which causes it to be moved to another approval status. These buttons (from the MESSAGEBUTTONS table) are available in the MT101 when the status is Complete. Queue Message Button Name Action Complete Save Save the message Print Print the message Exit Exit from Message page Queries Generate 195 Free Format Generate any other Free format message Next View the next message 2.1.4 Business Setup There are no system parameters, or business profiles specific to MT101 processing. 2.1.4.1 2.1.4.1.1 Business Rules Repair and Enrichment Selection Rule (Rule Type ID 145) Repair and enrichment rules must be defined to set Instruction ID/end-to-end ID for payments created from templates, in order to avoid duplication. Global PAYplus | Message Types | Business Guide Page 17 Rule Name Rule Sub Type MAP_F None EE_AC CT 2.1.4.1.2 Description Attached to And /Or Set debit fee Local office account on MT103, And generated from MT101 with F25 And Field/F Operator ield Value [Msg tp] SWIFT_ MAP_FEE_ 103 ACCT = [Orgnl = msg tp] SWIFT_ 101 [Orgnl fee acct] Empty Is not Action Data Manipulation Rule (Rule Type ID 146) This rule sets the MT103 debit fee. Since debit fees can be defined on the parent message, use of field tag 71G is also covered as part of GPP’s fee processing module, which processes instruction currency, message type, MOP (method of payment), and sending and receiving bank message attributes. Rule Name MAP_FEE_ ACCT Rule Sub Type Description Field/Field Operator Value Set debit fee account on MT103, generated from MT101 with Field 25 [Dbt fee acct nb] setVal [Orgnl fee acct] 2.1.5 Message Data 2.1.5.1 Message Attributes MT101 message type entry in MSG_TYPES table MT101 entry in MSG_TYPE_MOP table for SWIFT MOP Relation type in RELATIONTYPES table links the MT101 message with the de-bulked MT103 messages 2.1.5.2 Errors & Audit Trail There are no Errors and Audit Trail Messages specific to MT101 processing. Global PAYplus | Message Types | Business Guide Page 18 2.2 MT102 Message This section describes the processing of MT102 Multiple Customer Credit Transfer and MT102 STP (Straight-Through Processing) Multiple Customer Credit Transfer in GPP. 2.2.1 Overview This table shows the shared similarities and differences between MT102 and MT102 STP. Message Type Processing MT102 MT102 STP Similarities Sent by, or on behalf of, the FI (Sender) of the ordering customer(s) to another FI (Receiver) to credit a beneficiary customer directly or indirectly through a clearing mechanism or another FI, or to issue an amount to the beneficiary. Conveys multiple payment instructions between FIs Requires Prior Message User Group (MUG) registration. A MUG is a group of users who voluntarily agree to support the specified message type and are registered with SWIFT to send or receive the specified message type. For more information, see SWIFT Message Types in the SWIFT User Handbook. Maximum message input length 10,000 characters Bilateral/multi-agreements between Sender and Receiver Agreements cover transaction amount limits, the currencies accepted, and their settlement, and can change depending on FI, country, and other factors. Differences Uses a restricted set of MT102 fields and format options to enable the exchange of multiple customer credit transfers. This table provides differences between the message types, and additional behavior for MT102 STP. MT102 Field MT102 STP Field Option Field 119 To trigger the MT102 STP format validation, the user header of the message (block 3) is mandatory and must contain the code STP in the Validation Flag Field 119 ({3:{119:STP}}). Fields 52, 57 Can be used with the letter option A. Field 59 Subfield 1 (Account) of Field 59a is mandatory Field 51A Not used in MT102 STP. For MT102, this message may only be used on the FIN SWIFT network since it requires special validation. Field 72 Code INS must be followed by a valid financial institution BIC. Codes Reject (REJT) and Return (RETN) must not be used and must not include ERI information. Global PAYplus | Message Types | Business Guide Page 19 MT102 Field MT102 STP Field Option Field 23 Can contain codes CREDIT and SPAY. 2.2.1.1 MT102 Terminology This is a list of the terms and abbreviations used in this section. Term Description Parent message Bulked message MT102 or MT102 STP. Child message De-bulked individual payment message of MT102 or MT102 STP. Each child is handled as a single MT103 or MT103 STP respectively. 2.2.1.2 MT102 Sequences Both MT102 and MT102 STP consist of these sequences: Sequence Name Description A General Information A single occurrence sequence which contains information that applies to all individual transactions in Sequence B. B Transaction Details A repetitive sequence in which each occurrence provides details of a single individual transaction. Fields which appear in both Sequences (A and B) are mutually exclusive. C Settlement Details A single occurrence sequence that contains information about the settlement. For more information about mapping sequences to child messages, see Mapping. 2.2.2 Processing GPP does not perform SWIFT validations on incoming payments, incoming bulk MT102 or MT102 STP messages. 2.2.2.1 Incoming MT102 Process GPP uses these internal message types to process MT102 and MT102 STP incoming bulk messages: SWIFT_102 SWIFT_102 PLS Note: When a message subtype field is set to PLS, GPP formats the message in such a way that the message processes straight through (STP), with no errors. Bulk messages are defined with internal GPP message types and relevant business definitions: Message Type Message Sub Type Description SWIFT_102 N/A MT102 Multiple Customer Credit Transfer SWIFT_102 PLS MT102 STP Multiple Customer Credit Transfer Global PAYplus | Message Types | Business Guide Page 20 These message types identify inbound messages by parsing and storing them in the GPP DB. Once identified, the messages are processed. GPP supports these modes for processing bulk messages: Debit lump sum mode (with debit lump sum). From the Processing tab in the Parties profile, the Debit Lump Sum checkbox, if selected, maintains debit lump sum indication. Non-debit lump sum mode (without debit lump sum) The mode is determined during the debit side derivation and funds authorization step, and is based on the business setup at a customer level: If the setup instructs to perform debit lump sum on bulk messages, bulk messages undergo all further payment steps of the process. The debit leg of the posting is submitted as a single debit entry. Inbound bulk messages are parsed and stored in the GPP database. If no debit lump sum is required, bulk messages are sent directly to completion. Both debit and credit posting legs are performed on individuals. Note: As part of the Termination process, only successfully processed bulk messages continue to the process of de-bulking and mapping into individuals. When defining fee-related rules, these guidelines need to be considered: Debit lump sum mode: If a bulk message is an accounting message (indicated by the message class PAY), the debit side fees (where applicable) are set on the original parent message and the credit side fees (when relevant), are set on child individual payments. Note: GPP cancellation flow can reverse the respective individual account, which was already taken on the parent on the individual payment, if the linked parent’s message class is PAY. Non-debit lump sum mode: All fees (when relevant) are set on child individual payments. Fees are handled as per GPP core processing; this includes handling of fees as it is specified in Fields 71A and 71G if present. 2.2.2.2 De-bulking Parent Messages Inbound bulk messages are parsed and stored in GPP-SP DB. Bulk parent messages are de-bulked and mapped into child messages, and linked via MFAMILY. Child messages are mapped with information from the parent and are processed individually. To view details about parent/child linkage (MFAMILY), the user can click Links from the GPP Message page. How the parent message is processed determines the mode used to process the child message: In Debit lump sum mode, the debit leg previously done on the parent message performs the posting In Non-debit lump sum mode, the child message performs the posting 2.2.2.3 Mapping GPP creates one parent, and multiple child messages: The parent message includes Sequences A, B, and relevant sections from Sequence C The child message includes Sequence A, relevant sections from Sequence Bn, and relevant fields from Sequence C 2.2.2.3.1 Bulk and Individual Message Types and Mapping This table shows the SWIFT and internal GPP message type definitions and mapping of bulk information into individuals. For more information about sequences, see MT102 Sequences. Global PAYplus | Message Types | Business Guide Page 21 MT102 Multiple MT103 Single Customer Customer Credit Credit Transfer Transfer MT102 STP Multiple Customer Credit Transfer MT103 STP Single Customer Credit Transfer SWIFT Message Type MT102 MT103 MT102 STP MT103 STP GPP Message Type SWIFT_102 SWIFT_103 SWIFT_102, Sub Type PLS SWIFT_103, Sub Type PLS Sequence A Sequence A Sequence A Sequence A Sequence A Sequence B Sequence B1 … Sequence Bn Sequence Bm Sequence B1 … Sequence Bn Sequence Bm Sequence C Sequence C Sequence C Sequence C Sequence C 2.2.2.3.2 MT102 Multiple Customer Credit Transfer When an MT102 is received, these fields are mapped in GPP. No Status SWIFT Tag & Field Name Field Logical ID Content/Options General Information 1. Mandatory 20 File Reference 16x 2. Mandatory 23 Bank Operation Code 16x 3. Optional 51A Sending Institution [/1!a][/34x] 4!a2!a2!c[3!c] 4. Optional 50a Ordering Customer A, F, or K 5. Optional 52a Ordering Institution A, B, or C 6. Optional 26T Transaction Type Code 3!c Optional 77B Regulatory Reporting 3*35x 7. Optional 71A Details of Charges 3!a 8. Optional 36 Exchange Rate 12d Transaction Details (Repetitive) 9. Mandatory 21 Transaction Reference 16x 10. Mandatory 32B Transaction Amount 3!a15d 11. Optional 50a Ordering Customer A, F, or K 12. Optional 52a Ordering Institution A, B, or C 13. Optional 57a Account With Institution A or C 14. Mandatory 59a Beneficiary Customer No letter option, A, or F 15. Optional 70 Remittance Information 4*35x Global PAYplus | Message Types | Business Guide Page 22 No Status SWIFT Tag & Field Name Field Logical ID Content/Options 16. Optional 26T Transaction Type Code 3!c 17. Optional 77B Regulatory Reporting 3*35x 18. Optional 33B Currency/Instructed Amount 3!a15d 19. Optional 71A Details of Charges 3!a 71F Sender's Charges 3!a15d 20. 21. Optional 71G Receiver's Charges 3!a15d 22. Optional 36 Exchange Rate 12d Settlement Details 23. Mandatory 32A Value Date, Currency Code, Amount 6!n3!a15d 24. Optional 19 Sum of Amounts 17d 25. Optional 71G Sum of Receiver's Charges 3!a15d 26. Optional 13C Time Indication /8c/4!n1!x4!n 27. Optional 53a Sender's Correspondent A or C 28. Optional 54A Receiver's Correspondent [/1!a][/34x] 4!a2!a2!c[3!c] 29. Optional 72 Sender to Receiver Information 6*35x 2.2.2.3.3 MT102 STP Multiple Customer Credit Transfer When an MT102 is received, these fields are mapped in GPP. No Status SWIFT Tag & Field Field Logical ID Name Content/Options General Information 30. Mandatory 20 File Reference 16x 31. Mandatory 23 Bank Operation Code 16x 32. Optional 50a Ordering Customer A, F, or K 33. Optional 52a Ordering Institution A, B, or C 34. Optional 26T Transaction Type Code 3!c 35. Optional 77B Regulatory Reporting 3*35x 36. Optional 71A Details of Charges 3!a 37. Optional 36 Exchange Rate 12d Transaction Details (Repetitive) Global PAYplus | Message Types | Business Guide Page 23 No Status SWIFT Tag & Field Field Logical ID Name Content/Options 38. Mandatory 21 Transaction Reference 16x 39. Mandatory 32B Transaction Amount 3!a15d 40. Optional 50a Ordering Customer A, F, or K 41. Optional 52a Ordering Institution A, B, or C 42. Optional 57a Account With Institution A or C 43. Mandatory 59a Beneficiary Customer No letter option, A, or F 44. Optional 70 Remittance Information 4*35x 45. Optional 26T Transaction Type Code 3!c 46. Optional 77B Regulatory Reporting 3*35x 47. Optional 33B Currency/Instructed Amount 3!a15d 48. Optional 71A Details of Charges 3!a 71F Sender's Charges 3!a15d 49. 50. Optional 71G Sum of Receiver's Charges 3!a15d 51. Optional 36 Exchange Rate 12d Settlement Details 52. Mandatory 32A Value Date, Currency Code, Amount 6!n3!a15d 53. Optional 19 Sum of Amounts 17d 54. Optional 71G Sum of Receiver's Charges 3!a15d 55. Optional 13C Time Indication /8c/4!n1!x4!n 56. Optional 53a Sender's Correspondent A or C 57. Optional 54A Receiver's Correspondent [/1!a][/34x] 4!a2!a2!c[3!c] 58. Optional 72 Sender to Receiver Information 6*35x 2.2.2.4 Fees The following indicators may be used when defining user-defined business rules, for example, feerelated rules: Message Indication De-bulked Message Indicates if a message is a result of the de-bulking process, for example, an MT103 individual payment as a result of the MT102 bulked message de-bulking process. Global PAYplus | Message Types | Business Guide Page 24 Message Indication Bulk Message Indicates if this is a bulk message, containing information of multiple individual messages, for example, MT103 as a bulk message that contains information regarding individual MT103 payments. Bulk Message Class Indicates the message class of a bulk message, for example, PAY for Debit lump sum mode, or NAC for non-accounting debit lump sum mode. 2.2.2.5 Posting Generation of accounting entries are performed as per standard posting models. Customer specific configuration is covered by customization of posting solutions. The decision on whether bulk message is an accounting or a non-accounting message is done during the Debit side derivation process as part of the Payment classification step: The parent bulk message is considered as an accounting PAY message when the Debit lump sum field on the Parties profile is selected for a debit party, and associated with the processed payment. The bulk message continues with the High-value-like flow. When the Debit lump sum field on the Parties profile is not selected, the bulk message is classified as a non-accounting NAC message and proceeds to the Termination flow for completion and de-bulking. No accounting is done on the parent message – posting is done on individual payments only. The credit MOP is automatically set to BOOK. 2.2.3 Manual Handling 2.2.3.1 View Messages A GPP user can view and monitor bulk message details of the MT102 in the Message page. The Message page for individual MT103s provides information of specific bulk messages. The Properties tab of the Message page includes bulk-related information regarding the sum of amounts of individual messages. GPP prevents cancellation of completed bulk messages by disabling the Cancel button when MT102 and MT102 STP are in Complete status. 2.2.3.2 Message Actions MT102 has no message actions. 2.2.4 Business Setup There are no system parameters, or business profiles specific to MT102 processing. 2.2.4.1 2.2.4.1.1 Business Rules MOP (Method of Payment) Selection Rule (Rule Type ID 3) This rule, which applies to both MT102 and MT102 STP (with message sub type PLS), is used to determine and assign the method to be used to send the message. Note: When a message subtype field is set to PLS, GPP formats the message in such a way that the message processes straight through (STP), with no errors. Rule Name Rule Sub Type INC_B N/A ULK_M Description Attached to Select Credit MOP=BOOK Local office Global PAYplus | Message Types | Business Guide AND/ OR Field/ Field Operator Value/ Field/ Function Action [Msg tp] = SWIFT_10 BOOK 2 Page 25 Rule Name Rule Sub Type SG_10 2 2.2.4.1.2 Description Attached to AND/ OR Field/ Field Operator Value/ Field/ Function Action for incoming bulk messages 102 and 102 STP; should not exceed 1000 characters Credit Party Chain Enrichment (Rule Type ID 168) This rule is applicable for both MT102 and MT102 STP. GPP uses this rule to select a local office’s party for bulk MT102 and MT102 STP if processed as PAY (an accounting message, such as that used for debit lump sum mode.) Customer business requirements determine this rule’s setup. Rule Name Rule Sub Type INC_B N/A ULK_M SG_10 2 2.2.4.1.3 Description Attached to Select Local Office’s party for bulk MT102 and MT102 STP if processed as PAY Local office AND/ OR Field/ Field Operator Value/ Field/ Function Action [Msg tp] = [Msg class] = SWIFT_10Usage: Replace PAY First Credit Account Enrichment (Rule Type ID 170) This rule is applicable for both MT102 and MT102 STP. GPP uses this rule to select a credit suspense account for a single debit posting. Rule Name Rule Sub Type INC_B N/A ULK_M SG_10 2 2.2.4.1.4 Description Attached to AND/ OR Select credit Local office suspense account for the single debit posting for MT102 and MT102 STP Field/ Field Operator Value/ Field/ Function Action [Msg tp] = [Msg class] = SWIFT_10 Usage: Override account BI-Bypass Business Rule (Rule Type ID 47) This rule, available in the GPP user interface, is applied if it is required to skip debit account balance check on bulk messages. The actual setup is defined as per specific customer business requirements. This rule is applicable for both MT102 and MT102 STP. Global PAYplus | Message Types | Business Guide Page 26 Note: Criteria is controlled by the Interface Selection Rule (Rule Type ID 189) and is covered as part of the customization Balance inquiry solution. Rule Name Rule Sub Type INC_B N/A ULK_M SG_10 2 Description Attached to BI-bypass for bulk messages MT102 and MT102 STP, which are processed in GPP as PAY messages Local office AND/ OR Field/ Field Operator Value/ Field/ Function Action [Msg tp] = SWIFT_10 BYPASS 2 [Msg class] = PAY 2.2.5 Message Data 2.2.5.1 Message Attributes There are no Message Attributes specific to MT102 processing. 2.2.5.2 Errors & Audit Trail There are no Errors and Audit Trail messages specific to MT102 processing. Global PAYplus | Message Types | Business Guide Page 27 Message Types SWIFT Processing 2.3 MT203 Message This section describes the processing of MT203 messages received from SWIFT in GPP. The MT203 multi-message is sent by, or on behalf of, the ordering FI directly, or through correspondence, to the FIs of one or more beneficiary institution(s). Note: The MT203 message type does not require prior Message User Group (MUG) registration. 2.3.1 Overview The MT203 multi-message is used to order the movement of specific funds to each beneficiary institution. GPP parses and processes inbound MT203 messages and stores it in the GPP database. The message may contain order(s) for the movement of the Sender's own funds in favor of itself, for instance, when the Receiver services multiple accounts for the Sender and the funds are to be transferred between these accounts. MT203 can be sent to an FI to debit an account of the Sender serviced by the Receiver, and Credit an account owned by the Sender at an FI as specified in Field 57a. Each incoming MT203 is parsed and de-bulked into child MT202s. For information about MT203 attributes. 2.3.1.1 MT203 Terminology This is a list of the terms and abbreviations used in this section. Term Description Incoming MT203 containing two or more transactions received by an ordering FI. Onward MT203 messages received from an FI that contains orders for transfer of funds to one or more beneficiary FIs. Parent message The Bulked message MT203. Child message The de-bulked individual payment message of MT203. A child MT202 has the original message type of SWIFT_203. 2.3.1.2 MT203 Sequences The MT203 consists of these sequences types: Sequence Name Description A General Description Provides details of the transaction between the Sender and Receiver, that is, the value date and total amount to be transferred, as well as any other information about this transaction, as necessary. B Transaction Details Provides details of the transaction between the Receiver and the FI to which the funds will be transferred, and includes: The reference of the related transaction (TRN) The amount and currency code to be transferred The identification of the beneficiary institution and any other institution(s) through which the funds will pass Any other information about the transaction, as necessary Note: Sequence B must appear at least twice and, in order to expedite processing, not more than ten times. Global PAYplus | Message Types | Business Guide Page 28 Message Types SWIFT Processing 2.3.2 Processing GPP supports parsing and processing of inbound MT203 messages. 2.3.2.1 Incoming MT203 Process GPP processes the MT203 as follows: Parses and stores the MT203 in the GPP database. The MT203 is can be viewed in the GPP user interface, Message page This table provides information about the formats used with MT203. No Status SWIFT Tag & Field Name Field Logical ID Content/Options 1. Mandatory 19 Sum of Amounts 17d 2. Mandatory 30 Value Date 6!m 3. Optional 52a Ordering Institution A or D 4. Optional 53a Sender’s Correspondent A, B, or D 5. Optional 54a Receiver’s Correspondent A, B, or D 6. Optional 72 Sender to Receiver Information 6*35x 7. Mandatory 20 Transaction Reference Number 16x 8. Mandatory 21 Related Reference 16x 9. Mandatory 32B Currency Code, Amount 3!a15d 10. Optional 56a Intermediary A or D 11. Optional 57a Account With Institution A, B, or D 12. Mandatory 58a Beneficiary Institution A or D 13. Optional 72 Sender to Receiver Information 6*35x Manual Handling Maps the payment information, such as MID, Office, Department, Product Code Sets the Message Class to NAC (non-accounting message class De-bulks the MT203 into child MT202s Links the MT203 to child MT202s via MFAMILY in the ‘Bulk^Child’ relation type. For more information see MT203 De-bulking Completes the process Global PAYplus | Message Types | Business Guide Page 29 Message Types 2.3.2.2 SWIFT Processing MT203 De-bulking to MT202 Incoming MT203 messages are parsed and de-bulked into child MT202s as follows: Each child MT202 carries the original message type of the MT203. The child MT202 Original XML include MT203 Sequence A + respective Sequence B. The child MT202 is mapped with information from the parent MT203 and is processed individually in GPP. The child MT202 is processed in GPP in the high value flow, including debit/credit side derivation, debit authorization, fees, FX, MOP selection, Value date determination, Sanctions, Posting & Balance. Relevant debit authorization profiles need to be defined to allow the MT203 sender to debit F53 account according to the FI’s requirements. The child MT202 derives the debit account from the debit chain (Field 52, Field 53, Field 54) or the original sender. The child MT202 credit account is derived from Field 57 and Field 58. 2.3.2.3 MT203 Parsing This table shows the mapping of the original MT203 and respective logical fields for Sequence A. Original Incoming MT203 Logical Fields 19 OX_SUM_OF_AMOUNTS/X_SUM_OF_AMOUNTS 30 OX_STTLM_DT_1B/X_STTLM_DT_1B 52a OX_DBTR_AGT/X_DBTR_AGT *Including all sub-fields* 53a OX_INSTG_RMB_AGT/X_INSTG_RMB_AGT *Including all sub-fields* 54a OX_INSTD_RMB_AGT/X_INSTD_RMB_AGT *Including all sub-fields* 72 OX_INSTR_CDTR_AGT/X_INSTR_CDTR_AGT OX_INSTR_NXT_AGT/X_INSTR_NXT_AGT OX_INSTR_NXT_AGT_OTHER_CODES/X_INSTR_NXT_AGT_OTH ER_CODES OX_PRVS_INSTG_AGT_NM/X_PRVS_INSTG_AGT_NM *Including all sub-fields* 2.3.2.4 MT202 Mapping Incoming MT203 is parsed and de-bulked into child MT202s. GPP creates a child MT202 which will have the original message type of SWIFT_203. Child MT202 Original XML (Before tab) include MT203 General Information and Transaction Details. The parsed message fields of the MT202 will be as follows: Field Mapping F20 Mapped from MT203 respective Sequence B F20 F21 Mapped from MT203 Sequence B F21 Global PAYplus | Message Types | Business Guide Page 30 Message Types SWIFT Processing Field Mapping F32 Value Date Mapped from MT203 Sequence A F30 F32 Currency and Amount Mapped from MT203 Sequence B F32B F52 Mapped from MT203 Sequence A F52, if exists F53 Mapped from MT203 Sequence A F53, if exists F54 Mapped from MT203 Sequence A F54 (if exists) F56 Mapped from MT203 Sequence B F56 (if exists) F57 Mapped from MT203 Sequence B F57 (if exists) F58 Mapped from MT203 Sequence B F58 F72 F72 will be mapped from MT203 respective Sequence B F72, if exists; if not, mapped from F72 Sequence A (if exists) 2.3.2.5 MT203 Format This table provides information about the formats used with MT203. No Status SWIFT Tag & Field Field Logical ID Name Content/Options 1. Mandatory 19 Sum of Amounts 17d 2. Mandatory 30 Value Date 6!m 3. Optional 52a Ordering Institution A or D 4. Optional 53a Sender’s Correspondent A, B, or D 5. Optional 54a Receiver’s Correspondent A, B, or D 6. Optional 72 Sender to Receiver Information 6*35x 7. Mandatory 20 Transaction Reference Number 16x 8. Mandatory 21 Related Reference 16x 9. Mandatory 32B Currency Code, Amount 3!a15d 10. Optional 56a Intermediary A or D 11. Optional 57a Account With Institution A, B, or D 12. Mandatory 58a Beneficiary Institution A or D 13. Optional 72 Sender to Receiver Information 6*35x -----> -----| 2.3.3 Manual Handling 2.3.3.1 View Messages A GPP user can view messages from the Message page. Global PAYplus | Message Types | Business Guide Page 31 Message Types SWIFT Processing MT203 Message: GPP retains the links between the parent MT203 message and all child MT202 messages. These links can be viewed from the Links tab. Users can navigate from the parent MT203 to each child MT202 message. MT202 Message: The Before tab displays the message in original incoming XML format (MT203 Sequence A plus the respective Sequence B) as it was received. GPP retains the links between the parent MT203 message and all child MT202 messages. These links can be viewed from the Links tab. Users can navigate from the child MT202 to the parent MT203 message. 2.3.3.2 Message Actions MT203 has no message actions. 2.3.4 Business Setup There are no system parameters, business profiles or business rules specific to MT203 processing. 2.3.5 Message Data 2.3.5.1 Message Attributes The description for this message is MT203 Multiple General Financial Institution Transfer. This message appears as SWIFT_203 in the MSG_TYPES table. As defined in MSG_TYPES_MOP, this message appears as: MSG_TYPE=SWIFT_203 MOP=SWIFT 2.3.5.2 Errors & Audit Trail There are no Errors and Audit Trail Messages specific to MT203 processing. 2.4 MT204 Message 2.4.1 Overview The MT204 message is sent from an exchange, clearing house, or another financial institution (FI), to an FI to instruct the Receiver of the message to debit the account(s) of a third party as specified in the message, and to pay or credit the corresponding amount in favor of the Sender of the message. Note: The MT204 message type requires prior Message User Group (MUG) registration. A Message User Group (MUG) is a group of users who have voluntarily agreed to support the specified message type and have registered with SWIFT to send or receive the specified message type. For more information, see Error! Reference source not found.. Each incoming MT204 is parsed and de-bulked into child MT202s. For information about MT204 attributes, see MT204 Format. 2.4.1.1 MT204 Terminology This is a list of the terms and abbreviations used in this section. Term Description Incoming MT204 containing two or more transactions received by an ordering FI. Onward MT204 messages received from an FI that contains orders for transfer of funds to one or more beneficiary FIs. Parent message The bulked message MT204. Global PAYplus | Message Types | Business Guide . Page 32 Message Types SWIFT Processing Term Description Child message The de-bulked individual payment message of MT204. Each child of an MT204 is a single MT202 message. For more information about parent and child messages, see MT204 De-bulking. 2.4.1.2 MT204 Sequences MT204 consists of these sequences: Sequence Name Description A Common Elements Reimbursement details of a single occurrence sequence; contains default information valid for individual transactions (described in Sequence B) and the total amount to be reimbursed. B Transaction Details A repetitive sequence in which each occurrence provides details for one individual transaction (debit). An MT204 received from SWIFT with multiple instances of Sequence B will be de-bulked into individual MT202 messages for processing. Each child MT202 will have original message type of SWIFT_204. Child MT202 Original XML will include MT204 sequence A + respective Sequence B. Child MT202 original XML includes MT204 Sequence A and respective Sequence B. From the Message page, the user can click the Before tab to view the message type’s original XML. 2.4.2 Processing GPP supports parsing and processing of inbound MT204 messages. 2.4.2.1 Incoming MT204 Process GPP processes the incoming MT204 as follows: Parses and stores the MT204 in the GPP database. The MT204 is can be viewed in the GPP user interface, Message page. For more information, see Manual HandlingError! Reference source n ot found.. Maps the payment information, for example, MID, Office, Department, and Product Code data Sets the Message class to NAC (non-accounting message class GPP-SP de-bulks the parent MT204 into child MT202s, and links the MT204 and child MT202s via the MFAMILY table in the Bulk^Child relation type. For more information, see MT204 Debulking. 2.4.2.2 MT204 De-bulking GPP de-bulks the parent MT204 into child MT202s. Once de-bulked, the parent MT204 message status changes to Complete. Each child MT202 carries the original message type of the MT204. The child MT202 Original XML include MT203 Sequence A + respective Sequence B. The child MT202 is mapped with information from the parent MT204 and is processed individually in GPP. Global PAYplus | Message Types | Business Guide Page 33 Message Types SWIFT Processing The child MT202 is processed in GPP in the high value flow, including debit/credit side derivation, debit authorization, fees, FX, MOP selection, Value date determination, Sanctions, Posting & Balance. The child MT202s will derive the debit account from Field 53, quoted in the message. Credit account will be derived from F57/8 or the original sender. Since the sender of the MT204 is not the owner of the account in Field 53, debit authorization check will be done on the child MT202s. For more information see MT204 Parsing. For more information about mapping, see MT204 Parsing This table shows the mapping of the original MT204 and respective logical fields for Sequence A. Original Incoming MT204 Logical Fields Sequence A 20 OX_INSTR_ID/X_INSTR_ID 19 OX_SUM_OF_AMOUNTS/X_SUM_OF_AMOUNTS 30 OX_STTLM_DT_1B/X_STTLM_DT_1B 57A OX_CDTR_AGT/X_CDTR_AGT *Including all sub-fields* 58A OX_CDTR/X_CDTR *Including all sub-fields* 72 OX_INSTR_CDTR_AGT/X_INSTR_CDTR_AGT OX_INSTR_NXT_AGT/X_INSTR_NXT_AGT OX_INSTR_NXT_AGT_OTHER_CODES/X_INSTR_NXT_AGT_OTH ER_CODES OX_PRVS_INSTG_AGT_NM/X_PRVS_INSTG_AGT_NM *Including all sub-fields* This table shows the mapping of the original MT204 and respective logical fields for Sequence A. Original Incoming MT204 Logical Fields Sequence A 20 OX_INSTR_ID/X_INSTR_ID 19 OX_SUM_OF_AMOUNTS/X_SUM_OF_AMOUNTS 30 OX_STTLM_DT_1B/X_STTLM_DT_1B 57A OX_CDTR_AGT/X_CDTR_AGT *Including all sub-fields* 58A OX_CDTR/X_CDTR Global PAYplus | Message Types | Business Guide Page 34 Message Types SWIFT Processing Original Incoming MT204 Logical Fields *Including all sub-fields* 72 2.4.2.3 OX_INSTR_CDTR_AGT/X_INSTR_CDTR_AGT OX_INSTR_NXT_AGT/X_INSTR_NXT_AGT OX_INSTR_NXT_AGT_OTHER_CODES/X_INSTR_NXT_AGT_OTH ER_CODES OX_PRVS_INSTG_AGT_NM/X_PRVS_INSTG_AGT_NM *Including all sub-fields* MT202 Mapping This table lists the parsed message fields of the MT202. Field Mapping F20 Mapped from MT204 respective Sequence B F20 F21 Mapped from MT204 Sequence B F21 F32 Value Date Mapped from MT204 Sequence A F30 F32 Currency and Amount Mapped from MT204 Sequence B F32B F53 Mapped from MT204 Sequence B F53. The child MT202s derive the debit account from Field 53, as quoted in the message. Since the sender of the MT204 is not the owner of the account in Field 53, debit authorization check will be done on the child MT202s. Child MT202s derive the debit account from Field 53, as identified in the message. F57 Mapped from MT204 Sequence A F57, if exists F58 Mapped from MT204 Sequence A F58, if exists The credit account is derived from F57 and F58 of the original sender. If F57 and F58 do not exist in MT204 Sequence A, GPP maps F58 from the MT204 sender’s BIC. F72 Mapped from MT204 respective Sequence B F72, if exists. If not, map from F72 Sequence A (if exists). 2.4.2.4 MT204 Format This table provides information about the formats used with MT204. No Status SWIFT Tag & Field Name Field Logical ID Content/Options 1. Mandatory 20 2. Mandatory 19 Sum of Amounts 17d 3. Mandatory 30 Value Date 6!n Global PAYplus | Message Types | Business Guide Page 35 Message Types SWIFT Processing No Status SWIFT Tag & Field Name Field Logical ID Content/Options 4. Optional 57a Account With Institution A, B, or D 5. Optional 58a Beneficiary Institution A or D 6. Optional 72 Sender to Receiver Information 6*35x 7. Mandatory 20 Transaction Reference No. 16x 8. Optional 21 Related Reference 16x 9. Mandatory 32B Transaction Amount 3!a15d 10. Mandatory 53a Debit Institution A, B, or D 11. Optional 72 Sender to Receiver Information 6*35x 2.4.3 Manual Handling 2.4.3.1 View Messages A GPP user can view messages from the Message page: MT204 messages: GPP retains the links between the parent MT204 message and all child MT202 messages. These links can be viewed from the Links tab. Users can navigate from the parent MT204 to each child MT202 message. MT202 messages: The Before tab displays the message in original incoming XML format as it was received. GPP retains the links between the parent MT204 message and all child MT202 messages. These links can be viewed from the Links tab. Users can navigate from the child MT202 to the parent MT204 message. 2.4.3.2 Message Actions MT204 has no message actions. 2.4.4 Business Setup There are no system parameters, or business rules specific to MT204 processing. 2.4.4.1 2.4.4.1.1 Profiles Debit Authorization Profile The Debit Authorizations profile validates that senders of funds are authorized to debit an account that does not belong to them. The relevant debit authorization profiles need to be defined to allow the MT204 sender to debit F53 account. 2.4.5 Message Data 2.4.5.1 Message Attributes Within GPP, the MT204 Message description is MT 204 Financial Markets Direct Debit Message. MT204 message type entry in MSG_TYPES table: o MSG_TYPE = SWIFT_204 MT204 message type entry in MSG_TYPE_MOP for SWIFT MOP: o MSG_TYPE = SWIFT_204 Global PAYplus | Message Types | Business Guide Page 36 Message Types o 2.4.5.2 SWIFT Processing MOP = SWIFT Errors & Audit Trail There are no Errors and Audit Trail Messages specific to MT204 processing.MT 2.5 MT210 Message 2.5.1 Overview MT210 is an advance notice to the account servicing institution that it will receive funds to be credited to the Sender's account. The Notice to Receive information is contained on one tab: Notice to Receive Required - for message identification, Credit Account, Ordering Party, Intermediary Bank and Amount. 2.5.2 Processing GPP processes the message MT210 (notice to receive) for the following business scenarios: Service to Vostro Customer: Customers/financial institutions can send an MT210 for anticipated funds which they are expecting to receive in their accounts or one of its account serving institutions. It is used to track the projected end of day balance. GPP accepts such payments and supports automatic as well as manual matching with incoming receipt of funds (serial as well as cover messages). Multiple matching methods can be supported via system configuration. GPP supports full match as well as possible match. The possible match is to be manually reconciled and this is facilitated by an easy-to-use split screen user interface. Internal MT210 against Charges: GPP supports the automatic generation of MT210 messages when creating an outward MT191 - Request for Charges. These MT210s are used to track the expected charges. 2.5.2.1 Credit Anticipated Funds GPP displays the amount of MT210 as credit anticipated funds, meaning funds to be received at the Nostro account. Once matched with an incoming payment message such MT210s are no longer considered as credit anticipated funds. 2.5.2.2 Reversed MT210 GPP supports MT210 that are marked as “Reversed.” Such messages indicate anticipated funds to be withdrawn from a Nostro/Settlement account as a result from the bank’s own activity. Reversed MT210 can be either received from a feeder system or manually created. Reversed MT210 are accumulated into the debit anticipated funds figure on the position window as long as such messages were not yet matched with an actual payment message. Once matched with an outgoing payment message, reversed MT210 are no longer considered as debit anticipated funds. 2.5.2.3 Earmarking Reversed MT210 GPP enables the user to mark particular reversed MT210. By earmarking, GPP makes it possible to reserve liquidity with the amount mentioned in the reversed MT210. Once an outgoing payment message is matched with an “earmarked” MT210, it inherits the “earmark” indication and thus is entitled for the previously reserved liquidity. The amount of all earmarked MT210 that were not yet matched with an outgoing payment message impacts both the operating and the high payment capacities. This mechanism is particularly used for CLS payments. 2.5.2.4 Automatic 210 Matching GPP incorporates an automatic matching mechanism between anticipated funds and payment messages. This automatic mechanism is based on user defined rules. When a payment message or anticipated funds message are processed, GPP scans the predefined automatic matching rules to associates between the anticipated funds and the payment message or vice versa. If GPP was unable to find a unique match it indicates the possible candidates for matching. Global PAYplus | Message Types | Business Guide Page 37 Message Types 2.5.2.5 SWIFT Processing Manual 210 Matching In addition to the automatic matching, GPP enables manual reconciliation between a payment message to anticipated funds message. By highlighting both a specific payment message and a specific anticipated funds message via the various messages queues, they can link and match both messages. 2.5.3 Manual Handling 2.5.4 Business Setup 2.5.4.1 210 Matching 2.5.4.1.1 210 Matching – Background Definitions 210 Matching Fields The following table defines the fields of the payment and MT210 that are used in the MT210 matching algorithms. Field Name in Algorithm Field in Payment Currency Currency in F32A or F72/OCMT/ or Currency in F32B of the message F33B of the message (Mif.orig_currency (Mif.currency) or mif.ocmt_currency or mif.instruct_currency) Reference If reference in F21 exists then F21 else reference in F20 of the message (If Mif.orig_rfb not empty then Mif.orig_rfb Else Mif.orig_reference) Reference in F21 of the message (Mtf1000.rfb) Special Reference If Reference in F21 exists then F21 Else reference in F20 of the mesage (If Mif.orig_rfb not empty then Mif.orig_rfb Else Mif.orig_reference) Reference in F20 of the message (Mif.reference) Amount Amount in F32A or F72/OCMT/ or F33B Amount in F32B of the message of the message. (Mif.amount) (Either Mif.orig_amount or mif.ocmt_amount or mif.instruct_amount, depending on the first currency field that was matched) Value Date Value Date in F32A of the message (Mif.orig_value_date) Value Date in F30 of the message. (Mif.value_date) Paying Bank Sender of the message (Mif.orig_sender) BIC in F56 of the message. (mtf1000.ibk_bic) Originating Bank A BIC in F52 of the message (mtf1000.ogb_bic) Sender of the message (Mif.orig_sender) Global PAYplus | Message Types | Business Guide Field in 210 Page 38 Message Types Field Name in Algorithm SWIFT Processing Field in Payment Field in 210 (Bank specific for MT191) (Bank specific for MT191) Originating Bank B If a BIC exists in F52 then F52 BIC Else Sender of the message (If Mtf1000.ogb_bic exists then Mtf1000.ogb_bic Else Mif.orig_sender) BIC in F52 of the message. if the field is empty, then the originator is not available for matching (Mtf1000.ogb_bic) Credit party If F58 is “1st in Chain” then Account number in F58 if exists, or the Single non-asset-account of the beneficiary in F58A, or the preferred non-asset account of the beneficiary in F58A. Else the Credit Party is not available for matching (i.e. Matching steps containing this field will be skipped). Account number account in F25 if exists, or the Single Account of the Sender, or the Preferred Account of the Sender. Else the Credit Party is not available for matching (i.e. Matching steps containing this field will be skipped). (mtf1000.cr_acc_no) Beneficiary Account MTF1000.BNF (Customer in Field 59 in a 103 or Field 58 in a 202) Account number in F25 if exists, or the Single Account of the Sender, or the Preferred Account of the Sender. Else the Credit Party is not available for matching (i.e. Matching steps containing this field will be skipped). (mtf1000.cr_acc_no) Originating Party Corresponding Party (either F50 or F52) Mtf1000.Org Mtf1000.Org_Id Mtf1000.Org_Bic Mtf1000.Org_Addr1 Mtf1000.Org_Addr2 Mtf1000.Org_Addr3 Or Mtf1000.Ogb Mtf1000.Ogb_Id Mtf1000.Ogb_Bic Mtf1000.Ogb_Addr1 Mtf1000.Ogb_Addr2 Mtf1000.Ogb_Addr3 Corresponding Party (either F50 or F52) Mtf1000.Org Mtf1000.Org_Id Mtf1000.Org_Bic Mtf1000.Org_Addr1 Mtf1000.Org_Addr2 Mtf1000.Org_Addr3 Or Mtf1000.Ogb Mtf1000.Ogb_Id Mtf1000.Ogb_Bic Mtf1000.Ogb_Addr1 Mtf1000.Ogb_Addr2 Mtf1000.Ogb_Addr3 2.5.4.1.2 210 Predefined Matching Actions 1. The predefined matching actions are different methods according to which GPP scans the payment and the MT210 messages when searching for a possible matching. Each action describes different searching method. The actions use the comparison fields to detect a matching. 2. There are following predefined matching actions (methods): a. Rule action 210-1 b. Rule action 210-2 Global PAYplus | Message Types | Business Guide Page 39 Message Types c. SWIFT Processing Rule action 210-3 d. Rule action 210-4 e. Rule action 210-5 f. Rule action 210-C g. Rule action 210-6 h. Rule action 210-0 i. Rule action 210-J j. Rule action 210-CNA k. Stop action l. Rule action 210-IF 2.5.4.1.2.1 Rule Action 210-1 Search Scenario Steps: 1. Match by Amount, Value Date, Currency and Originating-Bank-B. If is match was found it is considered a full match. If a match was not found search according to the next step 2. Match by Amount + / - Tolerance, Value Date, Currency and Originating-Bank-B If is match was found it is considered a full match. If a match was not found search according to the next step Match by Amount + / - Tolerance, Value Date, Currency If is match was found it is considered a possible match. Steps 1-2: Search for messages with 210-match status equal to W or P, if the matched payment is SN it is a 210MATCHSN, otherwise 210MATCH Step 3: If payment: Search for messages with 210-match status equal to W or P If 210: Search for messages with 210-match status equal to W 3. Returned values in case of a full match: None 2.5.4.1.2.2 Rule Action 210-2 Search Scenario Steps: 1. Match by currency, special reference, amount and value-date If is match was found it is considered a full 210MATCHSN If a match was not found search according to the next step. 2. Match by currency, amount and value-date. If is match was found it is considered a possible 210POSAMT match If a match was not found search according to the next step 3. Match by currency, special reference and value-date If is match was found it is considered a possible 210POSREF match Step 1: GPP searches for messages with 210-match status equal to W or P. Steps 2-3: Global PAYplus | Message Types | Business Guide Page 40 Message Types SWIFT Processing If this matching was activated on a payment, GPP Searches for 210 messages with 210-match status equal to W or P. If this matching action was activated on an MT210, GPP Searches for messages with 210-match status equal to W. 4. Returned values in case of a full match: None 2.5.4.1.2.3 Rule Action 210-3 Search Scenario Steps: 1. Single match (count = 1) by: Reference, Currency, Paying Bank, Value Date, Office and Amount + / - Tolerance If is match was found it is considered a full match. If a match was not found search according to the next step 2. First of multiple matches (count >1) by: Reference, Currency, Paying Bank, Value Date, Office and Amount + / - Tolerance. Order by difference in amounts and take smallest difference. If a match was found it is considered a full match. If a match was not found search according to the next step 3. First Match by: Currency, Paying Bank, Value Date, Office and exact Amount If a match was found it is considered a possible match. Step 1: GPP Searches for messages with 210-match status equal to W or P. Steps 2-3: GPP Searches for messages with 210-match status equal to W. 4. Returned values in case of a full match: Credit account and Related reference number of the MT210 2.5.4.1.2.4 Rule Action 210-4 Search Scenario by Steps: 1. First Match by: Reference, Currency, Office and Amount + / - Tolerance If a match was found it is considered a full match. If a match was not found search according to the next step 2. First Match by: Reference, Currency and Office If a match was found it is considered a possible match by reference 210POSREF If a match was not found search according to the next step 3. First Match by: Amount, Currency and Office If a match was found it is considered a possible match by amount 210POSAMT Steps 1-3: GPP Searches for messages with 210-match status equal to W or P. 4. Returned values in case of a full match: Credit account and Related reference number of the MT210 2.5.4.1.2.5 Rule Action 210-5 Global PAYplus | Message Types | Business Guide Page 41 Message Types SWIFT Processing Search Scenario Steps: 1. First Match by Amount, Value Date, Currency and Originating-Bank-B If a match was found it is considered a full match If a match was not found search according to the next step 2. First Match by Amount + / - Tolerance, Value Date, Currency and Originating-Bank-B If a match was found it is considered a full match If a match was not found search according to the next step 3. First Match by Amount + / - Tolerance, Value Date, Currency If a match was found it is considered a possible match by amount 210POSAMT Steps 1-2: GPP Searches for messages with 210-match status equal to W or P. Step 3: If payment: GPP searches for MT210 with 210-match status equal to W or P If 210: Search for payment messages with 210-match status equal to W 4. Returned values in case of a full match: Credit account and Related reference number of the MT210 2.5.4.1.2.6 Rule Action 210-C Search Scenario Steps: 1. First Match by Amount, Value Date, Currency, Originating-Bank B and Credit Party If a match was found it is considered a full match If a match was not found search according to the next step 2. First Match by Amount + / - Tolerance, Value Date, Currency, Originating-Bank B and Credit Party If a match was found it is considered a full match If a match was not found search according to the next step 3. First match by Amount, Value Date, Currency, Originating Bank B and reference is a full match If a match was found it is considered a full match If a match was not found search according to the next step 4. Any match by Amount +/- tolerance, Value Date, Currency, Originating Bank B and reference If a match was found it is considered a possible match by amount 210POSAMT If a match was not found search according to the next step 5. Any match by Amount +/- tolerance, Value Date, Currency, Credit Party If a match was found it is considered a possible match by amount 210POSAMT If a match was not found search according to the next step 6. Any match by Amount +/- tolerance, Value Date, Currency and Originating Bank B If a match was found it is considered a possible match by amount 210POSAMT 7. Returned values in case of a full match: Credit account and Related reference number of the MT210 2.5.4.1.2.7 Rule Action 210-6 Search Scenario Steps: 1. First Match by: Reference, Currency, Office and Amount + / - Tolerance If a match was found it is considered a full match. If a match was not found search according to the next step Global PAYplus | Message Types | Business Guide Page 42 Message Types SWIFT Processing 2. First Match by: Special Reference, Currency, Office and Amount + / - Tolerance If a match was found it is considered a full match. If a match was not found search according to the next step 3. First Match by: Reference, Currency and Office If a match was found it is considered a possible match by reference 210POSREF If a match was not found search according to the next step 4. First Match by: Special Reference, Currency and Office If a match was found it is considered a possible match by reference 210POSREF If a match was not found search according to the next step 5. First Match by: Amount, Currency and Office If a match was found it is considered a possible match by amount 210POSAMT Steps 1-3: GPP Searches for messages with 210-match status equal to W or P. 2.5.4.1.2.8 Rule Action 210-J This rule is relevant when settlement amount is used in the 210 advice by the sender, but is different from the instructed amount in the payment (33B), because of FX conversions or fee charges. Search Scenario Steps: 1. First Match by: Beneficiary Account, Value Date, Currency and Amount If a match was found, set 210 match status = M. 2.5.4.1.2.9 Rule Action 210-CNA Search Scenario Steps: 1. First Match by: Amount + / - Tolerance1, Value Date, Currency, Credit Account If a match was found, set 210 match status = M and continue with step 2 If a match was not found, no matching will be done. 2. First Match by: Amount + / - Tolerance, Value Date, Currency, Credit Account, Related Reference (Payment F21 against 210 F20) - if exist If a match was found, set 210 match status = M and continue with step 4. If a match was not found, continue with step 3 3. First Match by: Amount + / - Tolerance, Value Date, Currency, Credit Account, Originating Party (ORG/OGB) If a match was found, set 210 match status = M, Select first record from step 3 as possible match and set 210 match status = P. If a match was not found, select first record from step 1 as possible match and set 210 match status = P 4. First Match by: Amount + / - Tolerance, Value Date, Currency, Credit Account, Originating Party (ORG/OGB), Related Reference (Payment F21 against 210 F20) - if exist 1 Tolerance is taken from credit account profile and if not found, from system option MATCHTOLRN. It is expressed in percentage of the amount Global PAYplus | Message Types | Business Guide Page 43 Message Types SWIFT Processing If a match was found, set 210 match status = M. Select first record from step 4 as possible match and set 210 match status = P. If a match was not found, select first record from step 2 as possible match and set 210 match status = P 2.5.4.1.2.10 Rule Action 210-0 1. This rule will be used in cases where we want the payment/210 to be eligible for matching but not to execute any searches. 2. Returned values in case of a full match: None 2.5.4.1.2.11 Stop 1. The STOP action is used to stop evaluating rules. 2. If a rule with the STOP action fits the message, then GPP will not evaluate any further rules and behave as if no fitting rule was found. In the context of 210 Matching Rules, this means that 210 Matching status will be N. 2.5.4.1.2.12 Rule Action 210-IF Match the incoming payment’s to the MT210’s attributes based on the below mentioned criteria. Note: In steps 1 to 5, GPP performs the search where Payment Message is ‘Non Feeder’ and ‘Non Manual Payments’ i.e. Orig MOP <> FEEDER, CREATE. Search Scenario Steps: 1. First Match by F32 Settlement Amount and Currency, F32 Value Date, Originating-Bank (compare against 52A, (11 or 8 characters BIC)), if F52 is not present then the Sender (11 or 8 character BIC) and Credit Party full 14 digits account number. If a match is found, it is considered as a full match. If a match is not found, search as per step 2. 2. First Match by F32 Settlement Amount + / - Percentage Tolerance (Refer System option MATCHTOLRN_IN_MT210) and Currency, F32 Value Date, Originating-Bank (compare against 52A, (11 or 8 character BIC)), if not present then the Sender (11or 8 character BIC) and Credit Party full 14 digit account number. If a match is found, it is considered as a Partial Match by Amount. If a match is not found, search as per step 3. 3. First Match by F32 Settlement Amount and Currency, Originating-Bank (compare against 52A, (11 or 8 character BIC)), if not present then the Sender (11 or 8 character BIC) and Credit Party full 14 digit account number. If a match is found, it is considered as a Partial Match by Amount. If a match is not found, search according to the next step 4. 4. First Match by F32 Settlement Amount + / - Percentage Tolerance (Refer System option MATCHTOLRN_IN_MT210) and Currency, Originating-Bank (compare against 52A,(11 or 8 character BIC)), if not present then the Sender (11 or 8 character BIC) and Credit Party full 14 digit account number. If a match was found, it is considered as a Partial Match by Amount. If a match is not found, search according to the next step 5. 5. First Match by F32 Settlement Amount and Currency, F32 Value Date, F21 Related Reference and Credit Party full 14 digit account number. If a match was found, it is considered as a Partial Match by reference. If a match was not found, then conclude as No Match search according to the next step. Global PAYplus | Message Types | Business Guide Page 44 Message Types SWIFT Processing Steps 6 to 7 where payment message is an incoming MT103 or MT103 (Msg_Type=103) spawned out of MT101 payment message to MT210 messages received earlier. Search Scenario Steps: 1. For messages from Source Feeder - First Match by F32 Settlement Amount and F32 Currency, F32 Value Date and Customer reference F20. (currently references in code word DNAR, EPAREF and ROLREF are replaced to F20 when message is received in GPP) If a match was found, consider it a Partial Match by reference. If a match was not found, then go to step 7. 2. Match by F32 Settlement Amount and F32 Currency, F32 Value Date. If a match is found, consider it a Partial Match by amount. If a match is not found, conclude it as No Match. Step 8 payment message is the incoming 202, 202COV or 202 spawned out of 203 to MT210 messages received earlier. Search Scenario Steps: 3. For messages from Source Feeder - First Match by F32 Settlement Amount and F32 Currency, F32 Value Date, against Field 21. If a match was found, consider it a Partial Match by amount. If a match is not found, conclude it as No Match. Step 1: GPP Searches for messages with 210-match status equal to W or P. Steps 2-8: If this matching was activated on a payment, GPP searches for 210 messages with 210-match status equal to W or P. If this matching action was activated on an MT210, GPP searches for messages with 210-match status equal to W. 2.5.4.1.3 210 Matching Scope 1. The scope of MT210 matching is to match payments and credit advices and unsolicited debit advices (MT103, MT202, MT205, MT910, MT900) on the one hand with MT210s or any other form of Anticipated Funds on the other. 2. MT210 Matching can be performed either automatically by setting up 210 Matching rules or manually via the 210 reconcile screen MT210 Types 1. GPP supports the following MT210 types - MT210 received from a customer indicating funds to be received to customer’s credit. This same MT210 may also indicate the bank’s Nostro where funds will be received. The Dr account is the Nostro; the Cr account is the customer account. - MT210 sent from the bank to its Nostro agent indicating funds to be received at the Nostro from a third part. This MT210 may originate within bank’s different departments and will be on-warded, if required, to the financial institution that services the Nostro account specified in the MT210. This same MT210 may also indicate the party from which the Nostro will receive the funds. The Dr account is the Nostro, the Cr account is the customer account. Global PAYplus | Message Types | Business Guide Page 45 Message Types SWIFT Processing - Internal MT210 that indicates anticipated receipt into a Nostro account and a customer account. This MT210 is not on-warded. The Dr account is the Nostro, the Cr account is the customer account. - Reverse MT210 - MT210 indicating anticipated funds to be withdrawn from a Nostro account held at another bank. This MT210 is not on warded by GPP. The Cr account is the Nostro account. 2. MT210s will be matched with payments as follows: - ANY payment that debits a Nostro is a candidate for matching to MT210s of type (a) – (c) above. - ANY payment that credits a Nostro is a candidate for matching to MT210 of type (d) above. 2.5.4.1.4 MT210 Anticipated Funds Recognition In order to consider an MT210 as anticipated funds, GPP activates the following steps: Accounts derivation Eligibility for matching Matching rules 2.5.4.1.5 Account Derivation 1. GPP first attempts to identify both the debit and credit accounts of the transaction that will match to the MT210. 2. The following table describes the criteria upon which GPP determines the debit and credit accounts involved in an MT210: Reverse Sender Receiver Dr Account Cr Account No Local bank Local bank An asset account associated The account mentioned in field 25 with the BIC mentioned in field 56, or Default Account per Payment Currency when field 56 is empty No Local Bank Other The account mentioned in field 25, or the local bank asset account with the Receiver when field 25 is empty N/A2 No Other Bank Local Bank An asset account associated with the BIC mentioned in field 56 , or the default Account per Payment Currency when field 56 is empty Account in field 25, or the Senders non asset account with the local bank when field 25 is empty Yes Local bank Local bank N/A An asset account associated with the BIC mentioned in field 56, or the default account per 210 2 Example: We send an MT200 to our Nostro B to transfer funds to Nostro C, and an MT210 to Nostro C. We expect to receive an MT910 from Nostro C that will match the MT210. The accounts of such a transaction are: Dr Nostro C, Cr Nostro B. From an MT210 perspecti ve Nostro B is not a relevant party, therefore we do not derive, in this scenario, a credit account for the MT210. Global PAYplus | Message Types | Business Guide Page 46 Message Types Reverse Sender SWIFT Processing Receiver Dr Account Cr Account 210 Payment Currency when field 56 is empty 3. As part of MT210 credit account identification process, GPP will search for account by account number first (ACCOUNTS.ACC_NO), If not found then by IBAN (ACCOUNTS.IBAN). 4. If GPP is unable to identify both the debit and the credit accounts, the MT210 match status is changed to N and the MT210 is not eligible for matching and is sent to the COMPLETE queue. 2.5.4.1.5.1 Eligibility for Matching 1. GPP determines whether the MT 210 is eligible for matching when at least one of the accounts (debit or credit accounts) is eligible for matching. An account is considered eligible for matching when the account has the 210 matching indication checked in the Account profile. 2. When both accounts are not eligible for matching, the MT210 message class is changed to NAC, the 210 match status is changed to N and the MT210 is not eligible for matching and is sent to the COMPLETE queue 2.5.4.1.5.2 210 Automatic Matching Rules 1. 210 Matching rules are invoked on payment messages after debit processing and after 1st in credit chain identification, but before PI/SN matching and Credit processing. 2. GPP invokes automatic matching on the following payments: - Incoming payments with message class PAY, PI, SN, DD, provided that the 1 st in credit chain is the final beneficiary (i.e. – that the payment will not be on-warded). - PAY, PI and SNs are matched to non-reverse MT210s. - DD are matched to reverse-210s. The source of the MT210 is irrelevant. 3. To invoke the rules on MT210s, GPP evaluates the default rules attached to the Local Bank in their attachment order. 4. To invoke the rules on payments, GPP evaluates the rules attached to the 1 st in credit chain, and if no fitting rule is found, GPP evaluates the default rules attached to the Local Bank in their attachment order. 5. If a fitting rule is not found, then there will be no attempt to match the payment to an MT210 or vice versa, and the payment or MT210 is assigned a 210-match status N (not for matching). In such case the MT210 message class is changed to NAC (non-accounting) message. 6. If a fitting rule is found, GPP first assigns 210-match status W (waiting) to the payment or to the MT210, and then uses the matching action of the rule to attempt to match the payment to a previously received un-matched MT210 or the MT210 to a previously received un-matched payment message. In case the payment does not find a matching MT210 or a possible match MT210, then the message is processed to completion. 7. GPP allows a payment message to be possibly matched to a single 210, but allows an MT 210 to be possibly matched to multiple payments. 8. In any case, whether a fitting rule is found or not, the MT210 is sent to the COMPLETE queue and the payment processing continues. 2.5.4.1.6 210 Matching Statuses 1. The result of the matching rule and the action associated with it may lead to the following possible matching statuses: - N - Not applicable for Matching, this status is received when: GPP recognizes that both the debit and the credit parties of the MT 210 are not eligible for matching Global PAYplus | Message Types | Business Guide Page 47 Message Types SWIFT Processing When a matching rule was not found By a user decision to manually modify the status value. - W - Waiting Match, this status is received when: › When the automatic matching rules were applied but no matching message was found › When the automatic matching rules were applied and the selected algorithm is 210-0 - M – Matched, this status is received when a payment message was matched either automatically or manually to a payment that is not an SN - S - Matched to SN, this status is received when an MT210 was matched to an SN message, or to a PI that was previously matched to an SN - either automatically or manually - P - Possibly matched, this status is received when GPP applied a matching algorithm which resulted in a possible match and not a full match. There are 2 types of possible matches: By amount or by reference. A user should manually resolve the possible match (by either manually confirming the match or manually un-matching). 2.5.4.1.7 Post 210 Matching Activities Once a payment message was matched with an MT210 either automatically or manually, the following activities occur: 2.5.4.1.7.1 Copy 210 Reference 1. Copy the 210 reference to the payment message-related reference, relevant only for non-reverse MT210. - - Payment Attributes –210 Reference Switching. The system automatically sets the value of this field to one of the values: › N - (no 210 match) the default value › M - (210 match with no reference switching), › R - (210 reference switching invoked). Payment Processing - before a full successful match, the payment attribute 210 Reference is empty and the payment attribute ‘210 Reference switching’ is set to N (no 210 match). After a full successful 210 match (either automatic or manual), GPP checks the payment credit account attribute ‘210 reference switching’ and performs the following: › If it is None, GPP leaves the payment attribute ‘210 Reference’ empty and sets the payment attribute ‘210 Reference Switching’ to M (210 match with no reference switching). › If it is F20, GPP sets the payment attribute ‘210 Reference’ to the contents of field 20 of the incoming MT210, and sets the payment attribute ‘210 reference switching’ to R (210 reference switching invoked). › If it is F21, GPP sets the payment attribute ‘210 Reference’ to the contents of field 21 of the incoming MT210, and sets the payment attribute ‘210 reference switching’ to R (210 reference switching invoked). 2.5.4.1.7.2 Copy Account Number 1. In the case of a non-reverse MT210s, the 210 account number is copied into the payment attribute 210 Account number, provided that the matching algorithm returns the credit account number of the MT210. 2. This is subsequently used in payment credit account derivation: GPP decides on the credit account in the following order of priority: a. Account entered by user b. Credit Processing Profile – Override account Global PAYplus | Message Types | Business Guide Page 48 Message Types c. SWIFT Processing Account from message d. Account from matched 210 z e. Credit Processing Profile – Default account 2.5.4.1.7.3 Post Match Relation Cleanup Once a payment message and an MT210 are matched either manually or automatically, the following occurs: The matched MT210 was a possible candidate for other payments – all such links will be deleted. If such payments do not have any other MT210s that is defined as possible candidate, their 210 status changes to W – waiting to be matched, instead of P – possible match. GPP re-invokes the matching mechanism in order to detect their actual matching status. The matched payment had other possible candidates – all the links will de deleted. If such MT210s are no longer linked to any other payment, their 210 status changes to W – waiting to be matched, instead of P – possible match. GPP re-invokes the matching mechanism in order to detect their actual matching status. 2.5.4.1.7.4 Archiving MT210 Messages Unmatched incoming MT210 messages may be retained for a longer period of time than regular payments as defined in system option - 210KEEP. To calculate which PI messages to move/clean GPP takes the Local Office business date minus the number of days set in system option 210KEEP.If the result is less than the payment value date and receipt date then the payment is moved to the history database. The parameter is set for a number and defines the number of working days. 2.5.4.2 2.5.4.2.1 Nostro Account Position Anticipated Funds Positioning 1. Un-matched anticipated funds to be received at a Nostro account will be reflected as credit anticipated funds 2. Un-matched anticipated funds to be withdrawn from a Nostro account will be reflected as the debit anticipated funds 3. The amount of already matched MT210s will not be taken into consideration by the Nostro account position as the matched payment amount is already reflected 4. MT210 marked as NAC – will not impact the Nostro account positioning 2.5.4.2.2 PI/SN Positioning 1. PI messages - The amount of PI messages for a specific value date which are still in the PAYSET queue is reflected in the not-yet settled credit figure on the Nostro Account Position screen. Once matched (either manually or automatically) or forced out of the PAYSET queue, the amount of the PI messages is no longer be taken into consideration as Not-yet settled funds, and is added to the settled credit figure. 2. SN messages – when an SN receives the complete status its amount is added to the settled payment figure on the Nostro Account Position screen. Global PAYplus | Message Types | Business Guide Page 49 Message Types SWIFT Processing 2.5.5 Message Data 2.5.5.1 210 Matching 2.5.5.1.1 210 Reconcile 1. The 210 Reconcile functionally enables manually matching of a payment message with an MT210s. The 210 reconcile is performed via the Reconcile 210 option on the Messages menu or via GPP different queues (e.g. Complete queue). 2. Using the 210 reconcile feature, a user can perform the following: - Create a match between an MT210 and a payment message - Confirm a possible match between an MT210 and a payment message - Un-match a possible match between an MT210 and a payment message 3. The manual reconcile option is activated by using the “210” button on the queue-toolbar. This button is available in the following queues: - AGED - COMPLETE - HELD - NSF - PAYSET - RECON210 (accessible via the Message Menu) - RELEASE - SCHEDULE 4. The following table summarizes the possible reconcile activities that can be performed via the Reconcile screen. Activity Description Match Used to match a 210 and a payment, or to confirm a possible match between a 210 and a payment. Show Matched … Used to display in the lower half the messages that are fully matched to the highlighted message in the upper half. Show Poss … Used to display in the lower half the messages that are possibly matched to the highlighted message in the upper half. Show All … Used to display in the lower half all messages that may be applicable for matching to the highlighted message in the upper half. Un-match Used to un-match the highlighted message in the lower half from the highlighted message in the upper half. 5. A payment in PAYSET queue can be opened and edited. The payment can be repaired, submitted and subjected to skip / verify rules. Reference: See the Manual payment handling functional specifications document for details. 2.5.5.1.2 210 Reconcile via the Message Menu 1. When opening the reconcile screen via the message options, a list of all MT210 that are either waiting to be matched or are possible matches is presented. Global PAYplus | Message Types | Business Guide Page 50 Message Types SWIFT Processing 2. By clicking the MT210 Reconcile icon, the screen is split. On the upper part of the screen the user can view a list of the still unmatched MT210, while on the lower part the user can view a list of relevant to MT210 matching payment messages. 3. The contents of the lower part of the screen are dynamically changed in accordance to the highlighted MT210 in the upper part of the screen as follows: Highlighted Message in List of Messages in Lower Half Upper Half Non-reverse MT210 waiting for a match All un-matched or possibly matched payments with message class PAY, PI or SN, with the same currency as the highlighted MT210, and with an amount within a certain tolerance of the MT210 amount. As specified by MATCHTOLMN system option. Reverse MT210 waiting for a match All un-matched or possibly matched payments with message class DD, with the same currency as the highlighted MT210, and with an amount within a certain tolerance of the MT210 amount. As specified by MATCHTOLMN system option. MT210 Possibly matched All possibly matched payments 4. The user can scroll between the payment messages displayed on the lower part of the screen. When a matching payment message is found, the user can match between the MT210 and the payment message by clicking the Match icon. 2.5.5.1.3 210 Reconcile via GPP queues The 210 Reconcile option may be accessed also from different GPP queues (e.g. Complete queue) by clicking the 210 Reconcile icon. The screen is split into two parts. - On the upper part of the screen the user can view all the messages that reside in that queue regardless of the message type, meaning the upper part of the screen lists MT210, payment messages or credit advices. - On the lower part of the screen, GPP dynamically displays relevant candidates for 210 matching according to the highlighted message on the upper part of the screen. Thus if a payment message is highlighted on the upper part of the screen, GPP displays all MT210 that are candidates for matching with the payment message. Vice versa if an MT210 is highlighted on the upper part of the screen, GPP displays all payment messages that are candidates for matching with the highlighted MT210 message. Highlighted Message in List of Messages in Lower Half Upper Half Non-reverse MT210 waiting for a match All un-matched or possibly matched payments with message class PAY, PI or SN, with the same currency as the highlighted MT210, and with an amount within a certain tolerance of the MT210 amount. As specified by MATCHTOLMN system option Reverse MT210 waiting for a match All un-matched or possibly matched payments with message class DD, with the same currency as the highlighted MT210, and with an amount within a certain tolerance of the MT210 amount as specified by MATCHTOLMN system option MT210 Possibly matched All possibly matched payments MT210 fully matched The fully matched payment Global PAYplus | Message Types | Business Guide Page 51 Message Types ISO 2022 Processing Highlighted Message in List of Messages in Lower Half Upper Half Payment with message class PAY, PI or SN waiting for a match All un-matched or possibly matched non-reverse MT210s with the same currency as the highlighted payment, and with an amount within a certain tolerance of the payment amount as specified by MATCHTOLMN system option Payment with a message All un-matched or possibly matched reverse MT210s with the same class DD waiting for a currency as the highlighted payment, and with an amount within a certain match tolerance of the payment amount as specified by MATCHTOLMN system option Payment possibly matched Possibly matched MT210 Payment fully matched The fully matched MT210 2.5.5.1.4 Repairing MT210 1. A 210 may fall to repair when the tag 25 is empty and multiple accounts are derived with any of the following option: - none preferred, or - multiple preferred accounts are found, or - receipt of an invalid credit account In this case, GPP is not be able to derive a credit account. 2. In the repair screen, it is possible to update / insert a credit account. 3. Once the MT210 is repaired, the system reassess whether a matching payment can be found. 2.5.5.2 View Messages Relations 1. Message relationships, e.g. PI/SN matched messages, 210 matched messages, are maintained and stored in GPP database. 2. This information can be viewed via the Linked Messages screen by clicking the Links icon. The screen lists all messages that are related to the current message. 3 ISO 2022 Processing 3.1 camt.054 Message camt.054 is a bank to customer debit/credit notification message. It provides a settlement view of all settled transactions and is an alternative to MT900 (Confirmation Debit), and MT910 (Confirmation Credit). The use of camt.054 format provides a uniform mapping in a standard format, certified by ISO20022. GPP can generate a camt.054 notification message for single transactions and only includes single transactions that are settled (for example, accounting transactions). camt.054 messages are generated with status BOOK (BOOK = camt.054 message status) and sent to the required creditors and debtors. These are the supported use cases: Creditor notification for settled transactions - Incoming credit transfer Debtor notification for settled transactions - Outgoing credit transfer Global PAYplus | Message Types | Business Guide Page 52 Message Types ISO 2022 Processing Creditor and debtor notifications for settled transactions - Credit transfer on us Debtor notification for settled transactions - Incoming Direct Debit Original Debtor notification for settled return Original Creditor notification for settled refund/reversal Original Debtor notification for settled refund/reversal Creditor notification for settled transactions - Incoming bulk credit transfer Debtor notification for settled transactions - Incoming bulk direct debit Global PAYplus | Message Types | Business Guide Page 53 Appendix A: Glossary This table provides definitions for terms used in this document. Term Description Child Message De-bulked individual payment message DB Database FI Financial Institution GPP Global PAYplus MUG Message User Group NAC Bulk Message Class: Non-Accounting message, such as that used for nondebit lump sum mode Parent Message Bulked message PAY Bulk Message Class: Accounting message, such as that used for debit lump sum mode PDO Payment Data Object STP Straight-Through Processing UI User Interface, also referred to as GUI (graphical user interface) Global PAYplus | Message Types | Business Guide Page 54
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Language : en-GB Tagged PDF : Yes XMP Toolkit : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26 Format : application/pdf Creator : D+H Description : Message Types Title : Business Guide Create Date : 2018:01:08 17:12:20+02:00 Creator Tool : Microsoft® Word 2016 Modify Date : 2018:01:08 17:12:30+02:00 Metadata Date : 2018:01:08 17:12:30+02:00 Producer : Microsoft® Word 2016 Document ID : uuid:21910a15-8038-487b-a20f-fb54f239f617 Instance ID : uuid:841135a0-d3d1-4b23-839e-85796da5caa6 Page Mode : UseOutlines Page Count : 54 Author : D+H Keywords : Global, PAYplus Subject : Message TypesEXIF Metadata provided by EXIF.tools