Standards Release 2017 (SR 2017): Frequently Asked Questions related to the SWIFT global payment innovation (gpi) service

Transcription

1 Standards Release 2017 (SR 2017): Frequently Asked Questions related to the SWIFT global payment innovation (gpi) service Frequently Asked Questions This document describes Frequently Asked Questions (FAQs) about SR 2017 changes linked to SWIFT gpi. This document is intended for anyone who needs more information about the impact of SWIFT gpi on Market Infrastructures and Financial Institutions (including gpi and non-gpi banks) in SR June 2017

2 Table of Contents Table of Contents... 2 Preface... 3 Purpose of the document... 3 Intended Audience... 3 Related documentation What is SWIFT gpi? What is SWIFT gpi? Where can I find more information about SWIFT gpi? Who can become a SWIFT gpi member? Background info about SWIFT gpi-related fields in FIN MT Which fields distinguish a gpi payment from a non-gpi payment? What is the Unique End-to-End Transaction Reference (UETR)? What is the Service Type Identifier? Who will use the UETR and Service Type identifier? How will I be informed of future standards-related changes related to gpi? SWIFT gpi-related changes in SR 2017 for banks What are the SWIFT gpi-related changes in SR 2017 for banks? As a non-gpi bank, can I forward gpi fields to the next party in the transaction chain? Will SWIFT validate the gpi-data in the Header of the MT 103? How can I test that I am able to receive the gpi-related data in the MT 103? What about MT 202 COV? What about the MT 199? What about the MT 101? What about the MX payments messages? What about the impact on FINInform? As a non-gpi Bank, how will the gpi Tracker use my data? SWIFT gpi-related changes insr 2017 Impact on Market Infrastructures What is the impact on Market infrastructures using FINCopy (Y or T-mode)? Are other FINCopy features or messages impacted? What can a Market Infrastructure do with gpi data? How can a Market Infrastructure on Y-Copy test the gpi fields? How will payment Market Infrastructure using SWIFT in V-shape mode support gpi transactions? What about Payment Market Infrastructures using FINInform? What about Payment Market Infrastructures not using SWIFT? What about Payment Market Infrastructures with plans to implement ISO 20022? Legal Notices April

3 Preface Purpose of the document This document describes Frequently Asked Questions (FAQs) about the SR 2017 impact of changes linked to SWIFT gpi on Market Infrastructures and financial institutions (gpi and nongpi banks). Intended Audience This document is for the following audience: Technical implementers of the Standards MT messages Operational users of the Standards MT messages All other interested SWIFT users Related documentation Standards MT Release 2017 timeline Standards MT Release Guide 2017: Standards Release Guide FIN System Messages Advance Information FIN Operations Guide Advance Information Extended Use of SWIFT gpi Fields 111 and 121 SWIFT gpi: Recording of webinars: April

4 1. What is SWIFT gpi? 1.1 What is SWIFT gpi? SWIFT s global payments innovation (gpi) is a platform designed to improve the customer experience in cross-border payments by increasing their speed, transparency, and traceability. It is the live service derived from the global payments innovation initiative that was launched in December The SWIFT gpi platform brings together the world s leading transaction banks from Europe, Asia Pacific, Africa and the Americas to significantly improve cross-border payments. SWIFT gpi is a robust response to evolving bank and corporate needs for enhanced customer service and operational efficiency. It delivers an enhanced value proposition for correspondent banking by addressing key challenges the industry faces. To achieve this, gpi banks agree to respect service-specific business rules and technical requirements captured in a rulebook. Live in a SWIFT gpi CUG (Closed User Group) since February 2017, SWIFT gpi focuses on business-tobusiness payments, in a first phase. Designed to help corporates grow their international business, improve supplier relationships, and achieve greater treasury efficiencies, the service enables corporates to experience an enhanced payments service directly from their banks. 1.2 Where can I find more information about SWIFT gpi? Visit or download the brochure to find out more about gpi, its member banks, vision, timeline etc. 1.3 Who can become a SWIFT gpi member? Any supervised financial institution (SUPE) that is a member of SWIFT and adheres to the business rules of the global payments innovation initiative can join the new service and become a gpi member. To receive more information on the benefits of joining gpi directly, please contact us on swiftforbanks@swift.com or visit April

5 2. Background info about SWIFT gpi-related fields in FIN MT 2.1 Which fields distinguish a gpi payment from a non-gpi payment? The SWIFT gpi service relies on the correct usage of the MT 103, MT 103 STP and MT 103 REMIT. Additionally, to flag a payment as a gpi payment, two new fields have been introduced in the User Header (Block 3): Field 121: contains the Unique End-to-End Transaction Reference (UETR) Field 111: contains the gpi Service Type Identifier These fields must be included in the User Header (Block 3) of the FIN MT exchanged in the framework of SWIFT gpi. More information on the FIN Header Block 3 and details of field 111 and 121 are available in the Operations Guide on swift.com. 2.2 What is the Unique End-to-End Transaction Reference (UETR)? An end-to-end payment transaction typically involves multiple MT messages, exchanged between different parties involved in the end-to-end payments chain. In order to uniquely identify and track the lifecycle of the transaction to which these different messages relate, the SWIFT gpi service has introduced the usage of a unique gpi end-to-end transaction reference (UETR), a SWIFT tracking number. The UETR used in SWIFT gpi messages is based on a well-known and mature mechanism for generating such an identifier: the Universally Unique Identifier (UUID), sometimes also known as Globally Unique Identifier (GUID), compliant with IETF standard RFC 4211 using version 4 of the generation algorithm. The format consists of 36!x composed of 32 hexadecimal characters, displayed in 5 groups separated by hyphens: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx x = any hexadecimal character (lower case only); y is one of 8, 9, a or b. The UUID is designed to be globally unique, without risk of repetition over time. Example: {121:eb6305c9-1f7f-49de-aed c27b42d} The UETR is included in field 121 in the User Header (Block 3 of a SWIFT MT). The UETR is generated by the gpi instructing bank (the first gpi bank in the payment chain) when initiating a payment and communicated together with the gpi Service type Identifier (field 111) in the User Header 2.3 What is the Service Type Identifier? In order to flag a payment as a gpi payment, the gpi instructing bank will include the service type identifier in field 111 of the User Header. The value for the currently defined gpi service type is 001. SWIFT will validate that the service type identifier complies with the format 3!n. The number itself is not validated. Additional numbers may be used in the future for other gpi service types. The Service Type Identifier must always be accompanied by the UETR (field 121) in the User Header. 2.4 Who will use the UETR and Service Type identifier? The unique gpi end-to-end transaction reference (UETR) is generated by the gpi instructing bank (the first April

6 gpi bank in the payment chain) when initiating a payment and communicated together with the gpi service type identifier in the User Header of the payment MT. These fields are transported throughout the gpi end-to-end payment s lifecycle: Field 111 and field 121 must both be present or both absent (error code U12) Together these two fields will: highlight to the receiving gpi bank that the payment has to be processed according to the service level guaranteed in the gpi rulebook, allow SWIFT to update the gpi tracker with real-time status information about a specific transaction allow gpi banks to consult and update the status of a specific transaction in the gpi tracker As of SR 2017, gpi banks will be able to send these two new fields to non-gpi banks as well. Non-gpi banks will not be allowed to create or forward these 2 fields: Use of field tags 111 and 121 is restricted to the gpi Closed User Group (error code G27) 2.5 How will I be informed of future standards-related changes related to gpi? Future gpi standards-related changes will be communicated as per the normal SWIFT Standards Release process. April

7 3. SWIFT gpi-related changes in SR 2017 for banks 3.1 What are the SWIFT gpi-related changes in SR 2017 for banks? gpi-related data in MT 103/MT 103 STP/MT 103 REMIT Since SR 2016, gpi banks can already exchange gpi payments with field 111 and 121 in the User Header, in the gpi Closed User Group (CUG). The change request for SR 2017 was given the number CR and requested non-gpi MT 103 message receivers to be able to receive the field 111 and field 121 in the User Header. The submitter was the gpi community, sponsored by US NMG. The main aim was to enhance the end-to-end tracking of payments when non gpi banks are involved in the payment (also 1 leg outside the gpi CUG) and facilitate payments input by allowing gpi banks to put the extra fields in all MTs 103 they send, irrespective of the receiver being a gpi bank or a non-gpi bank. 3.2 As a non-gpi bank, can I forward gpi fields to the next party in the transaction chain? For SR 2017, non-gpi banks cannot forward the gpi-related fields in the header of the MT 103. It was agreed that non-gpi banks must be able to receive the gpi data in the User Header only, no processing or forwarding requirements. Should this become a requirement in the future, a change request will need to be raised, which will be handled as part of a (future) normal standards release process. In case a non-gpi bank sends the gpi data in the User Header, it will receive a NAK (error code G27). 3.3 Will SWIFT validate the gpi-fields in the Header of the MT 103? SWIFT will validate that: The sender is registered to the gpi CUG (error code G27) gpi fields (111 and 121) are both present or absent in the User Header (error code U12) the format of the UETR complies with xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is any hexadecimal character (lower case only) and y is one of 8, 9, a, or b the format of the Service Type Identifier is correct (3!n) 3.4 How can I test that I am able to receive the gpi-related data in the MT 103? For banks wanting to test the new fields, SWIFT s Test and Training system will be available as of 23 July FIN has a repository of sample messages known as the tank file. A Test and Training user can request FIN to generate and output a sample of FIN current or future user-to-user Test and Training messages. SWIFT will add MT 103 sample messages which contain the new gpi data to the tank file. You can request these MT messages by sending an MT 073 Message Sample Request. More information is available in the FIN Service Description. April

8 3.5 What about the MT 202 COV? In SR 2017, non-gpi banks only have to be able to receive the UETR and service type identifier in the MT 103, MT 103 STP and MT 103 REMIT. SWIFT gpi banks are already sending and receiving MT 103s with gpi-fields in the User Header in the gpi CUG. As part of the evolving gpi service portfolio, gpi banks may start exchanging other payment messages in the gpi CUG, such as the MT 202 COV This will allow tracking of MT 202 cover flows (related to the MT 103) and notifying the cover parties in case of settlement issues, missing or non-compliant cover. As gpi banks will exchange MT 202 COV in the gpi CUG, the implementation can be done outside of the Standards Release process. The same also applies to the MT 205 COV. These evolving requirements may result in future change requests that could impact non-gpi banks. Change requests will be handled through the normal Standards Release process. 3.6 What about the MT 199? gpi banks currently exchange MT 199s to update the transaction status in the gpi tracker within the gpi CUG. As of April 2017, gpi banks can exchange these MT 199s with the gpi tracker, or use API calls to update/receive info from the gpi tracker. This means there is no impact on the MT 199 for non-gpi financial institutions. 3.7 What about the MT 101? In the first phase gpi business rules are only applicable to gpi banks for their correspondent banking flows. SWIFT is working together with the whole community (banks, corporates and partners) to explore business rules for corporates to be able to flag a gpi payment within the credit transfer request (MT 101 Request for Transfer and ISO payment initiation messages). For more information contact SWIFT at swiftforbanks@swift.com Today, in order to benefit from the gpi service, corporates need to agree with their banks to initiate gpi payments for specific flows and currencies; this will be covered by the T&C s agreed with each bank. 3.8 What about the MX payments messages? Because the gpi service is focussing on correspondent banking, the decision was in a first phase to look at the MT payments messages, as today there is no official migration plan towards ISO in the correspondent banking space (which does exist in the MI space, see question 4.7). The possible use of ISO in a later phase of gpi will be discussed by the gpi vision group. For more information contact SWIFT at swiftforbanks@swift.com 3.9 What about the impact on FINInform? As part of normal FINInform processes, the complete Header Block of user-to-user messages is included in the MT 096 copied to a copy destination for the MT messages indicated in the parameters of the FINInform service. If the MT 103 is part of this, there will be an impact (in SR 2017) on the MT 096 if the sender of the original MT 103 message is a gpi bank and included field 111 and field 121 in the User Header of the original message. The information of the MT 103 will be present in block 4 of the MT 096 (also when the parameters of FINInform only indicate a partial copy, because the partial is only linked to block 4 of the original MT 103). April

9 {1:F01BANKGB2LACMR } {2: O DYLPXXXXXXXX S} {3:{ABC}{108: MUR OF MT 096} {4: {1:F01SNDRGB22AXXX } {2:I103RCVRGB2LAXXX U} {3:{108:XY/T44961}{111:001}{121:eb6305c9-1f7f-49de-aed c27b42d}} {4: :20:TRANSFER :23B:CRED :32A:140902GBP150000,00 :33B:STG150000,00 :50K:/ BIODATA LTD 46 GREEN LANE CAMBORNE CORNWALL TR14 7EQ ENGLAND :59:/ H.F. TRELAWNEY 68 MARK LANE LONDON EC2 ENGLAND :71A:SHA -} {5: {CHK:81EC89D79E80}} {5:{CHK:CHECKSUM OF MT 096}{SYS:SYSTEM TRAILER OF MT 096}} The MT 096 will contain a copy of the original message for all MTs incorporated by the parameters of the specific FINInform service If the gpi service expands to other MT messages (for example MT 202 COV outside the standards release cycle), there will also be an impact on the MT 096 copying the MT 202 COV when both the sender and the receiver are gpi banks, as the MT 096 is payment message agnostic As a non-gpi Bank, how will the gpi Tracker use my data? By enabling non-gpi banks to receive gpi data in payments, the gpi tracker will be able to increase the reach of the transaction status made available through the tracker and confirm the reception of a gpi payment to the previous agents in the transaction chain. Information that will be available in the tracker: The sender s reference (field 20) of the message that was sent to the non-gpi bank The date and time when the non-gpi bank received the message (based on the UAK (User Acknowledgement) Non-gpi banks do not have access to the tracker. April

10 4. SWIFT gpi-related changes in SR 2017 Impact on Payments Market Infrastructures (PMI) 4.1 What is the impact on PMIs using FINCopy (Y or T-mode)? As part of normal FINCopy processes, the complete Header Block of user-to-user messages is included in the MT 096copied to a FINCopy destination. As gpi-related changes introduced in the User Header (new field 111 and 121) were introduced late in the SR 2016 process, it was agreed to temporarily shield Market Infrastructures from the impact of introducing these new fields for gpi banks. This means that, gpi banks can exchange gpi payments across all SWIFT MIs using Y-Copy. For information about the new fields, please see Section 2 of this document. As part of SR 2017, SWIFT will resume its copy-as-usual functionality, which means that MIs using FINCopy, will receive the gpi fields in the MT 096 as part of the User header block of the copied message. Market infrastructures just need to be able to receive the new fields. As gpi banks may start exchanging other payment messages (such as the MT 202COV) in the near future within the gpi Closed User Group (CUG), Market infrastructures should be aware that, if gpi banks exchange these payment messages containing the gpi fields in the User Header, these fields will also be copied to the MT 096. The MT 096 is payment message agnostic; it does not distinguish between a copy of eg MT 103 or MT 202COV. 4.2 Are other FINCopy features or messages impacted? There is no impact on other FINCopy features, nor on any of the other system messages used in FINCopy. 4.3 What can a PMI do with gpi data? As of SR 2017, Market Infrastructures (MIs) using FINCopy must be able to receive the new gpi fields in the MT 096. They do not have to include these fields in any subsequent FINCopy messages. SWIFT will use the data to automatically update the transaction status in the gpi tracker. MIs do not have to update the tracker, nor do they have access to the tracker. As of SR 2017, FINInform users will receive the gpi data as part of the FINCopy to Server Destination April

11 Message (MT 096) linked to the original credit transfer. FINInform also uses the MT 096 to copy the payment message. The same impact as described above applies. 4.4 How can a PMI on Y-Copy test the gpi fields? Market Infrastructures using FINCopy in Y-Copy mode can test the new gpi data elements copied in the MT 096 as of 23 July 2017: Using Local Test Mode to test with SWIFT: SWIFT will add MT 096 and MT 103 sample messages which contain the new gpi data to the tank file. MIs can request these MT 096 messages by sending an MT 073 Message Sample Request. This mode will be available as of 23 July Using Full Function Mode to allow MIs to test with themselves: to enable Market Infrastructures to test with themselves, SWIFT can add the MI test BIC to the test-gpi CUG. MI will need to request this through a dedicated form. This enables the MI to benefit from its full Test and Training environment to send test MT 103s with the new gpi data elements and the service identifier in the User Header between an MI s test-and training destinations. The new gpi data elements will then be included in the MT 096 copied to the FINCopy Test and Training destination, allowing an MI to simulate testing with its service participants. Using Full Function Mode to allow MIs to test with their members: if feasible, Market Infrastructures could set up tests with a number of their service participants, as of 23 July Please contact swiftforbanks@swift.com for additional information. 4.5 How will a PMI using SWIFT in V-shape mode support gpi transactions? For V-shaped payment Market Infrastructures using standard FIN messaging, the same changes as for non-gpi banks will apply. These changes are documented in section 3 of this document. As of SR 2017, gpi banks can send payments with gpi data to these Payment Market Infrastructures (PMI). These PMIs need to be able to receive the gpi fields included in the User Header of the MT 103, MT 103 STP and MT 103 Remit. Market Infrastructures operating in V-shape mode, cannot yet forward the gpi fields in the User Header of the onward MT 103. SWIFT is currently investigating how these Payment Market Infrastructures could potentially forward the gpi data to gpi and non-gpi banks. If you are a Market Infrastructure using SWIFT in a V-shaped mode and interested in supporting gpi payments, please contact us on swiftforbanks@swift.com. For details regarding the new gpi fields, see section 2 in this document. 4.6 What about PMIs using FINInform? As of SR 2017, FINInform users will receive the gpi data as part of the FINCopy to Server Destination Message (MT 096) linked to the original credit transfer. FINInform also uses the MT 096 to copy the payment message. The same impact as described in question 4.1 applies. 4.7 What about PMIs not using SWIFT? SWIFT is in contact with some of the world s largest payment Market Infrastructures not using SWIFT to establish local market practices, developed in collaboration with select gpi member Banks and SWIFT, to enable the exchange of SWIFT gpi transactions between their members. Next to available market practices for the Fed, CHIPS and CIPS (RMB), this includes the development of local market practices for Japan and Switzerland. April

12 In addition, SWIFT is actively engaging with key Payment Market Infrastructures worldwide to further extend the gpi experience and ensure global interoperability between domestic and cross-border payments services. 4.8 What about PMIs with plans to implement ISO 20022? For communities that will implement ISO in the (near) future, SWIFT is developing a new global market practice that can be used by any community that will start to adopt ISO for High-Value Payments Systems..All major Payment Market Infrastructures and representatives of PMPG (Payments Market Practice Group) banks are part of this initiative. April

13 Legal Notices Copyright SWIFT All rights reserved. Confidentiality This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside your organisation without SWIFT s prior written consent. Disclaimer SWIFT supplies this publication for information purposes only. The information in this publication may change from time to time. You must always refer to the latest available version. Trademarks SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: the SWIFT logo, SWIFT, SWIFTNet, SWIFTReady, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo, MyStandards, and SWIFT Institute. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners. April