Extending benefit of track/stop payments to all SWIFT banks (SR 2018) August, 2017

Transcription

1 Extending benefit of track/stop payments to all SWIFT banks (SR 2018) August, 2017

2 Background and business drivers Following introduction of new header fields in MT 103 with SR 2016, gpi banks have been tracking payments between them With SR 2017, they will be able to track payments to first non-gpi bank; all SWIFT users must be able to receive (but not process) gpi payments (*) Tracking payments allows to improve the service offered to corporate clients. In addition, it enables services like Stop and Recall payment message, increasingly relevant in today s cybercrime and security context With SR 2018, we can bring the tracking/stopping benefits to the entire SWIFT community, make it the new norm, as a SWIFT feature The presence of a unique end-to-end transaction lifecycle reference in any cross-border transaction benefits gpi & non-gpi banks, it makes interbank & customer communications on enquiries, investigations & fraud detection more effective and efficient (*) non-gpi banks may ignore tags 111 ( 001 ) and 121 (UETR) in MT 103 messages if not relevant for the back-office 2

3 SR 2018: making track and stop payment the new normal SR 2016 Track payments (and SLA) by gpi banks SR 2017 Track payments to non-gpi banks SR 2018 Track and stop payments by all banks gpi banks gpi banks gpi banks MT 103, UETR SWIFT banks SWIFT banks SWIFT banks 3

4 What, why Objective: increase security and trust in SWIFT network overall Step 1: SR 2016 Track payment, by gpi banks 40 banks send/receive gpi banks can track payments between them CRs: 2 new fields in header, gpi banks send and receive MT 103 with UETR in gpi CUG Step 2: SR 2017 Track payment, to non-gpi banks 140 banks send + 10,000 receive gpi banks put UETR on all their MT 103, including to non-gpi, extend tracking to next/last leg CRs: all banks able to receive MT 103 with UETR Step 3: SR 2018 Track/stop payment, by all banks All 10,000 SWIFT banks send and receive tracked payments All banks benefit from tracking information and use unique end-to-end identifier in communication with other banks CRs: All banks able to receive cat 1 and cat 2 with UETR, all banks send/relay MT 103 with UETR, all banks send/relay MT 202 / 205 and COV with UETR DRIVERS DRIVERS DRIVERS Piloting, within CUG Establish rules, tracking, designing v2 services Easier implementation for gpi banks A first step to make gpi the new norm Bring value of tracking to entire SWIFT community Ability to track any payment, incl. non-gpi instructions Ability to stop any payment on SWIFT with gsrp service, incl. non-gpi instructions 4

5 From following single messages to Transaction Life Cycle Tracking Message Ref. 1 Message Ref. 2 Message Ref. 3 Message Ref. 4 Message Ref. 5 UETR UETR UETR UETR Business Areas PAYMENTS Adding a UETR on each message allows to monitor the end-toend transaction SWIFTgpi Tracker Payments status/progress AVAILABLE Observer Analytics Business Intelligence Transaction Life Cycle BANK TRANSACTION MONITORING & COMPLIANCE SERVICES Compliance Analytics Financial Crime Risk Alerting Payment Controls Detect/prevent fraud & crime SWIFT Products & Services Other Services AML, work-flow, investigations COMING ASSESSMENT ASSESSMENT TBC SECURITIES TRADE Banks can more easily monitor the life cycle in addition to individual messages SWIFT products and services can offer transaction monitoring and controls Tracking is available now for payments, other areas can be assessed in the future 5

6 4 CRs submitted to SR 2018 CHANGE REQUEST Receive UETR CR 1337 Ability to receive fields 111 and 121 on any cat.1 and cat.2 message Tracking/stopping all MT 103 CR 1338 Mandatory UETR on MT 103, send and pass on BENEFITS Real-time visibility of more transactions on SWIFT network - for SWIFT gpi banks and their customers Logical extension of SR 2017, limited to MT 103 for non-gpi receivers Supports extension of SWIFT gpi service with MT 202 COV and MT 205 COV tracking End-to-end real-time visibility of MT 103 on SWIFT network - for SWIFT gpi banks and their customers Supports new stop and recall service for GPI and non-gpi intermediates Systematic utilisation of UETR brings additional operational, anti-fraud, security and compliance benefits for the entire community, incl. non-gpi banks Extension tracking to MT 202/5 cov & 202/5 Mandatory UETR on MT 202cov and MT 205cov, send and pass on CR 1339 Mandatory UETR on MT 202 and MT 205, send and pass on CR 1340 End-to-end real-time visibility of MT 202 COV, MT 205 COV, MT 202 and MT 205 on SWIFT network - for SWIFT gpi banks and their customers Supports extension of SWIFT gpi service with MT 202 COV and MT 205 COV tracking Systematic utilisation of UETR brings additional operational, anti-fraud, security and compliance benefits for the entire community, incl. non-gpi banks 6

7 How - Interfaces Roadmap to accommodate SR2018 gpi change requests Support by SWIFT interface Sending Bank Include UETR on MT 103, 202/205 Dedicated programme to back-office application vendors, to include UETR Alliance interfaces to support appending UETR if not provided by back-office (*) Feedback UETR MT 103 to back-office (for inclusion in 202/205COV) Receiving Bank Be able to receive cat 1 and cat 2 with UETR Can be ignored by back-office if not relevant No/minimal impact, since all banks / interfaces already to be able to receive MT 103 with UETR with SR 2017 Intermediary Bank Pass on UETR when linked to same transaction MT 103 intermediary traffic very concentrated as 455 or 11% banks do 97% intermediary traffic, majority gpi banks by end 2018 MT 202 & COV even more concentrated as ~200 banks do 90% Q3 Q4 Q1 Q2 Q3 Q4 A S O N D J F M A M J J A S O N SAA/E /AMH MST2017 roll-up SR2017 Alliance releases for 7.2 SAG/SNL 7.2 Alliance Messaging Hub 3.6 Vendor Communications Interface & back-office vendors Highlighting requirements for SR2018 Exact date to be defined SAA/E /AMH MST2018 roll-up Alliance releases for SR2018: Alliance Access/Entry Alliance Messaging Hub Alliance Lite2 - Outgoing MT103, MT202, MT205: automatically add a new UETR in Block3 (field 121) when not populated by back-office - Feedback new UETR to back-office (for supporting MT202COV, MT205COV flows) End-of-Support SNL/SAG 7.0.x SAA/E 7.1.x SR2018 (*) Alliance interfaces GUI for manual entry already supports generation of UETR 7

8 What is in it for the SWIFT community With the UETR on any transaction, all banks on SWIFT can use such unique reference to identify end-to-end cross-border payments for enquiries, investigations and fraud prevention The UETR is a key enabler for developing a community service for tracking and stopping payments on SWIFT, including services to non-gpi banks SWIFT is exploring an extension of the gpi service to offer a basic version of the payment tracking and stopping services for any bank on SWIFT, making it a new norm and standard service available to all banks This requires a UETR to be present in all messages 8

9 Increasing security and trust in SWIFT network overall SR 2017 gpi banks benefit from track/stop to gpi and first non-gpi bank SR 2018 Extending benefit of track/stop payments to any SWIFT bank gpi banks gpi banks MT 103, UETR 3 MT 103, UETR 2 gpi light Opt-in service Tracker 4 MT 103, UETR 1 5 Tracker 4 MT 103, UETR MT 103, UETR 1 MT 103, UETR SWIFT banks SWIFT banks Limitations for gpi banks 1 No end-to-end payments tracking number 2 Tracker only provides traceability until first non-gpi bank 3 Payments cannot be stopped beyond gpi banks Limitations for non-gpi banks 1 Small banks cannot benefit from end-to-end payments tracking number 4 Small banks do not have access to Tracker 5 Small banks cannot benefit from stop payment services Benefits for gpi banks 1 Payments can be in the Tracker end-to-end 2 Payments can be stopped beyond today s gpi community (*) Benefits and opportunities for non-gpi banks 3 Unique reference to identify cross-border payments end-to-end Increasing security and trust in network overall 4 gpi light banks have access to the Tracker (**) 5 gpi light banks can stop payments (gpi light rulebook) (**) 9 (*) gpi bank will only be able to stop payments at non-gpi bank if latter opted in for the gpi light service (**) non-gpi bank will need to opt-in for gpi light service to be able to stop payments and access the Tracker

10 When 10

11 Follow and comment on MT change requests in MyStandards 11

12 12

13 SR2018 support in FIN interface and back-office applications 13

14 Mandatory support of UETR by all FIN interfaces Mandatory requirement for all FIN interfaces Append UETR field by interface if not present auto-generation => all relevant messages will have UETR, no NAKs Pass on UETR: intermediary traffic very concentrated as 228 banks do 95% all likely to be gpi. For remaining / decreasing % over time, if same UETR not passed-on, payment is not NAK-ed and shown in Tracker as new transaction due to auto-generation Certify & monitor all FIN interfaces Add in Alliance portfolio roadmap for SR delivery July 2018 Publication on swift.com 20 FIN interface applications in operation Interface Functional Requirements For all outgoing MT103, analyse Block3 contents When field 121 (UETR) is not present, generate UETR based on RFC4122 and add field 121 with valid UETR Configurable: send status update to back-office with MT103 field :20: (Sender s Reference) and field 121 (UETR) 14

15 SWIFT will limit the impact of SR2018 on the back-office applications 1. Ability to receive fields 111 and 121 on any cat.1 and cat.2 message The UETR can be ignored if back-office not ready and fields not relevant (yet) No/minimal impact, since all banks / interfaces already to be able to receive MT 103 with UETR with SR Mandatory UETR on MT 103, MT 202cov, MT 205cov, MT 202 and MT send and pass on Mandatory auto-generation of UETR field by all FIN interfaces if not provided by back-office - All relevant messages will have UETR, no NAKs Including and passing on UETR field will be included in the SWIFT certified applications for gpi - Mandatory requirement for label criteria Technical validation process will perform tests on these capabilities in the application 15

16 Payment application vendor certification programme Certification programme for payments application vendors that support SWIFT gpi Ensure gpi capabilities available by default Generation and processing of gpi-enabled payments instructions, in accordance to the gpi Customer Credit Transfer rulebook; Support access to information in the gpi Tracker and gpi Directory; Provide support for the SWIFT payments standards, including the gpi unique end-to-end transaction reference; Commit to supporting the gpi strategic roadmap, enabling future gpi payments services and functionalities To be launched week Sep 4, 2017 Big push at Sibos 4 key vendors already used by live banks, in conversation with 30 additional vendors 16

17 Dedicated communication and engagement programme to vendor community Q3 Q4 Q1 Q2 Q3 Q4 J A S O N D J F M A M J J A S O N D SR2017 APRIL to JUNE SR2018 Vendor Communications Interface & back-office vendors Highlighting requirements for SR2018 Vendor webinars SR2018 mandatory requirements review Operational Newsletter Premium Customer update SR2018 Discussion Paper to PMWG Vendor webinars Heads-up: SR2018 impacts on interface & back-office applications Interface Spec s Vendors & Application providers SR2018 MANDATORY req s Update Conformance statement on swift.com MT Standards Release 2018 in T&T mode SR2018 gpi activation Go/No Go decision FIN Interface certification Application provider certification swift.com update Customer campaign to ensure readiness End of Country Voting SR 2018 Standards MT Nov 2018 Updated High-Level Information SR2018 Webinars Focused on gpi changes (end Feb/beginning March) Implementation of CRs in SR2018 swift.com 17

18 gpi Payments Tracking Services (gcct) 18

19 Key features: The SWIFT gpi Tracker Function End-to-end payments tracking database to monitor progress of a gpi payment Benefits Allowing to track a payment s path in real time, obtain transparency on deducts and confirmation that payment was credited One-glance status overview Track path, in real time Details of banks along the chain Transparency of total fees and time Unique, end-end tracking number Availability MT 199 / API: Today Central payments database, hosted at SWIFT Updated via MT199 or API Data consumption via GUI, via MT199 (push) or via API (pull) 19

20 Generation of UETR 20

21 gpi s Unique End-to-End Transaction Reference Requirement gpi Customers must include the UETR into gpi payments messages and their confirmations so they can be identified and tracked. The reference caters for Intermediary gpi Agent scenarios and provides a unique endto-end reference across the payment transaction. Considerations The UETR is designed to be globally unique, without risk of repetition over time. Technical specification The UETR is Located in tag 121 (36!x) in FIN block 3 (user header) Generated without central co-ordination, and populated by Instructing gpi Agent in first gpi MT 103 Passed on unchanged, throughout gpi interbank chain in any gpi payment instructions and confirmations Format specification: The UETR field is created and populated using the UUID specification (IETF s RFC using version 4 of the generation algorithm), in lower case. The format of this field is xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is any hexadecimal character (lower case only) and y is one of 8, 9, a, or b. Format will be validated by FIN as of SR2017. As of 19 November 2017, FIN messages carrying an incorrectly formatted UETR will be rejected (error code U13). Use of tags 111 and 121 will require sender and receiver to be in the gpi CUG. When this is not the case, use of these tags will result in a NAK (error code G27). Tags 111 and 121 must both be present or both be absent (error code U12). After SR2017, use of tags 111 and 121 will require only sender to be in the gpi CUG. When this is not the case, use of these tags will result in a NAK (error code G27). Sample for FIN block 3 {3: {111:001}{121:eb6305c9-1f7f-49de-aed c27b42d} } gpi Customer Credit Transfer (gcct) Service rulebook Advance Information 7 July 2017 Do not disclose this publication outside your organisation without SWIFT s prior written consent. SWIFT All rights reserved. Order of tags in block 3:

22 UETR field in SWIFT messages IETF RFC Universally Unique IDentifier (UUID) standard UETR (SWIFT tracking number) Unique end-to-end transaction reference. This reference contains Universally Unique IDentifier (UUID) compliant with version 4 of standard RFC4122. It is transported in field tag 121 of gcct messages. The format of this field is: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is any hexadecimal character (lower case only) and y is one of 8, 9, a, or b. Format will be validated by FIN as of Standards Release UUID Standard This specification defines a uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDS (Globally Unique IDentifier). A UUID is 128 bits long and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation s (OSF) Distributed Computing Environment (DCE), and then in Microsoft windows platforms. One of the main reasons for using UUIDs is that no centralised authority is required to administer them. As a result, generation on demand can be completely automated, and used for a variety of purposes. Example: 7e b-41e7-1bb5-4b0fde7c5320 UUIDs are easy to generate, e.g. in Java import java.util.uuid; // Standard Java feature UUID uuid = UUID.randomUUID(); // Make a UUID String uuid36 = uuid.tostring(); // Get it as a character string 22

23 Sending and receiving tags 111 ( 001 ) and 121 (UETR) in MT 103 SR 2016 Track payments (and SLA) by gpi banks gpi banks SR 2017 Track payments to non-gpi banks gpi banks Non-gpi banks SR 2018 Track and stop payments by all banks Non-gpi banks & traffic gpi banks or non-gpi Bank Non-gpi banks MT 103, UETR MT 103, UETR gpi banks & traffic gpi banks or non-gpi Bank Non-gpi banks MT 103, (001), UETR 23

24 gpi Stop & Recall Payment (gsrp) 24

25 SWIFT gpi - Stop & Recall Payment Value Proposition How can SWIFT gpi help? Standardized market practice for Delivering requests for cancellation through gpi Tracker directly to processing bank Efficiently cancelling a payment on request of the client or any gpi Bank within the payment chain Effectively stop an active payment anywhere it is in the processing chain Request to recall the funds in case the beneficiary was already credited to initiate the return of funds back to the gsrp requestor Service Benefits Reduction of operating cost Increased customer satisfaction Enhanced risk management SWIFT gpi Tracker MT 192, MT 199 / API 1 4 MT 199 / API 1 4 STOP Requested MT 199, MT 196 / API 3 2 Payment Cancelled MT 192 / API Debtor Debtor s Bank Intermediary Bank Intermediary Bank Creditor s Bank 5 Return of Funds FIN Creditor gpi Stop & Recall Payment (gsrp) Service rulebook Advance Information 30 June 2017 Do not disclose this publication outside your organisation without SWIFT s prior written consent. SWIFT All rights reserved. 25

26 Alliance interfaces portfolio support for gpi 26

27 Alliance Access MT103 27

28 AMH MT199 28

29 SR2017 Communications 29

30 Communications SR2017 CR : Ability to receive Unique End-to-End Transaction Reference (UETR) Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 J F M A M J J A S O N D J F M A M J J A S O N D SR2016 SR2017 Vendor Communications Interface & back-office vendors Highlighting requirements for SR2018 Operational Newsletter SR2017 Discussion Paper to PMPG Broadcast all SWIFT Users SRG Publication SR Guide Webpage Extended Use SWIFT gpi Fields 111 / 121 Knowledge Base tip Country Votings SR2017 CR 1265 Standards MT Nov 2017 Updated High-Level Information SR2017 Webinars Focused on gpi changes Vendor webinars SR2017 impacts on interface & back-office applications Bilateral discussions Top 30 payment application vendors GPI roadmap incl. SR 2017 impacts UGC Newsletter swift.com MT Standards Release 2017 in T&T mode Implementation of CRs in SR107 30