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 2017.

4 April 2017
Table of Contents

Table of Contents ...................................................................................................................................2

Preface .....................................................................................................................................................3
Purpose of the document ............................................................................................................................ 3
Intended Audience ...................................................................................................................................... 3
Related documentation ............................................................................................................................... 3
1. What is SWIFT gpi? ......................................................................................................................4
1.1 What is SWIFT gpi? .................................................................................................................... 4
1.2 Where can I find more information about SWIFT gpi? ................................................................ 4
1.3 Who can become a SWIFT gpi member? ................................................................................... 4
2. Background info about SWIFT gpi-related fields in FIN MT .....................................................5
2.1 Which fields distinguish a gpi payment from a non-gpi payment? .............................................. 5
2.2 What is the Unique End-to-End Transaction Reference (UETR)? ............................................. 5
2.3 What is the Service Type Identifier? ........................................................................................... 5
2.4 Who will use the UETR and Service Type identifier? ................................................................. 5
2.5 How will I be informed of future standards-related changes related to gpi? ............................... 6
3. SWIFT gpi-related changes in SR 2017 for banks .....................................................................7
3.1 What are the SWIFT gpi-related changes in SR 2017 for banks? .............................................. 7
3.2 As a non-gpi bank, can I forward gpi fields to the next party in the transaction chain? .............. 7
3.3 Will SWIFT validate the gpi-data in the Header of the MT 103?................................................. 7
3.4 How can I test that I am able to receive the gpi-related data in the MT 103? ............................ 7
3.5 What about MT 202 COV? .......................................................................................................... 8
3.6 What about the MT 199?............................................................................................................. 8
3.7 What about the MT 101?............................................................................................................. 8
3.8 What about the MX payments messages? ................................................................................. 8
3.9 What about the impact on FINInform? ........................................................................................ 8
3.10 As a non-gpi Bank, how will the gpi Tracker use my data? ........................................................ 9
4. SWIFT gpi-related changes inSR 2017 Impact on Market Infrastructures .........................10
4.1 What is the impact on Market infrastructures using FINCopy (Y or T-mode) ? ........................ 10
4.2 Are other FINCopy features or messages impacted? ............................................................... 10
4.3 What can a Market Infrastructure do with gpi data? ................................................................. 10
4.4 How can a Market Infrastructure on Y-Copy test the gpi fields? .............................................. 11
4.5 How will payment Market Infrastructure using SWIFT in V-shape mode support gpi
transactions? ............................................................................................................................................. 11
4.6 What about Payment Market Infrastructures using FINInform? ............................................... 11
4.7 What about Payment Market Infrastructures not using SWIFT? .............................................. 11
4.8 What about Payment Market Infrastructures with plans to implement ISO 20022? ................. 12
Legal Notices ........................................................................................................................................13

April 2017 2
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 non-
gpi 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: www.swift.com/gpi
Recording of webinars: https://www.swift.com/standards/standards-
resources?category=7021

April 2017 3
 1. What is SWIFT gpi?

1.1 What is SWIFT gpi?

SWIFTs 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 2015. The SWIFT gpi platform
brings together the worlds 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-to-
business 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 www.swift.com/gpi 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 www.swift.com/gpi.

April 2017 4
 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-aed0-16487c27b42d}

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 2017 5
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 payments 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 2017 6
 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 CR001265 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, SWIFTs Test and Training system will be available as of 23 July
2017. 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 2017 7
 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 20022 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&Cs 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 20022 in the
correspondent banking space (which does exist in the MI space, see question 4.7).
The possible use of ISO 20022 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 2017 8
{1:F01BANKGB2LACMR2245224778}
{2: O0961409021011DYLPXXXXXXXX24442365571409021111S}
{3:{ABC}{108: MUR OF MT 096}
{4:
{1:F01SNDRGB22AXXX3461486137} {2:I103RCVRGB2LAXXX U}
{3:{108:XY/T44961}{111:001}{121:eb6305c9-1f7f-49de-aed0-16487c27b42d}}
{4: :20:TRANSFER
:23B:CRED
:32A:140902GBP150000,00
:33B:STG150000,00
:50K:/122267890
BIODATA LTD
46 GREEN LANE
CAMBORNE
CORNWALL TR14 7EQ
ENGLAND
:59:/50266959
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.

3.10 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 senders 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 2017 9
 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 2017 10
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 2017.
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 MIs 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 2017.
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 worlds 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 2017 11
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 20022 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 20022 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 2017 12
 Legal Notices
Copyright
SWIFT 2017. All rights reserved.
Confidentiality
This publication contains SWIFT or third-party confidential information. Do not disclose this publication
outside your organisation without SWIFTs 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 2017 13