High-Level Information

Transcription

1 This document describes the requested changes for the next Standards MT Release. These requests must still be validated by a maintenance working group and some may be modified or rejected. Country user groups must still vote the approved requests and the Board must ratify those that are accepted by the country vote. This document also includes other technical changes that are foreseen for implementation at the same time as the Standards MT Release. The purpose of this document is to help technical implementers and operational users of the Standards MT messages to evaluate the impact of changes on interfaces and applications. 20 July 2018

2 Table of Contents Table of Contents Preface Introduction Schedule for SR Levels of the Change Requests Evaluation of the on Interfaces and Applications Category 0 FIN System s Other Technical Changes Category 1 Customer Payments and Cheques Category 2 Financial Institution Transfers Category 3 Foreign Exchange, Money Markets, and Derivatives Category 4 Collections and Cash Letters Category 5 Securities Markets Category 6 Commodities and Reference Data Category 7 Documentary Credits and Guarantees/Standby Letters of Credit Category 8 Travellers Cheques Category 9 Cash Management and Customer Status Category n Common Group s...25 Legal Notices July

3 Preface Preface About this document This document gives an overview of all MT change requests received by SWIFT Standards for the next Standards MT Release. The purpose of this document is to inform the SWIFT community and allow them to start allocating budget and resources for the next maintenance of the Standards MT messages. Technical implementers and operational users of the MT messages can use this document to evaluate the impact on interfaces and applications. This document is not intended to be final. All change requests need to be validated by a maintenance working group (MWG) and can be subject to modification or rejection. After the MWG decision, user group chairpersons of all countries are able to discuss the change requests in their user group and vote on the acceptance or rejection of individual change requests. The SWIFT Board must ratify the outcome of the country vote. 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 20 July

4 Introduction 1 Introduction Important This document describes changes that are still requests. These requests must be validated by a maintenance working group and a number of them will be rejected. Country user groups must then vote the approved requests and the Board must ratify those that are accepted by the country vote. The document is part of the normal standards development and implementation procedures. This document describes the expected or requested changes for Standards MT Release 2019 (SR 2019). SWIFT distributes this document 16 months before the Standards MT Release live date. This document also includes other technical changes that are foreseen for implementation at the same time as the Standards MT Release, for example, changes to system messages. The sole purpose of this document is to help technical implementers and operational users of the SWIFT messages to evaluate the impact of changes on interfaces and applications. Consequently, implementers and users can plan resources and budget allocations for SR 2019 implementation. As this document describes requests that are not yet validated, a certain number of them will not be implemented or will be implemented differently following the validation process. Readers must therefore use this document for budget and resources planning purposes only. The Standards Release Guide 2019, which SWIFT will publish in December 2018, will fully describe SR Approved changes will be effective as of 17 November 2019, the release date on FIN. Note This publication is supplied for information purposes only, and shall not be binding nor shall it be construed as constituting any obligation, representation or warranty on the part of SWIFT. The information in this publication is the latest available at the date of its production, and may change. 20 July

5 Schedule for SR Schedule for SR 2019 The timeline below describes the schedule for development and implementation of SR SR 2019 Timeline The only official source for information about a Standards MT Release is the Important Standards Release Guide that is published in December. 20 July

6 Levels of the Change Requests 3 Levels of the Change Requests All change requests contain an evaluation of their impact on interfaces and applications expressed as a number in the range 0-3 with or without a plus "+" or minus "-" sign as in the following table. Index of impact s Level 0 Level 1 This is a minor change that does not impact the format of the message. For example, the scope of the message is updated, which may have an impact on some automated applications. This change relates to the use of the message format but does not affect the message structure or the FIN validation, for example, a definition or a usage rule is changed. Level 1+ Level 2- Level 2+ Level 3- Level 3 An existing message type is removed from the network The change has a small effect on the message structure and the FIN validation, for example, field formats, qualifiers or codes are added or deleted. The message layout or the FIN validation or both are significantly impacted, for example, fields or sequences (mandatory or optional) are added or deleted. A new message type is created for use in a message user group () or the use of an existing message type is changed from use in a to general use, that is, all users must be able to receive and process the new message. A new message type is created for general use, that is, all users must be able to receive and process the new message. 20 July

7 Evaluation of the on Interfaces and Applications 4 Evaluation of the on Interfaces and Applications on interfaces All changes can have a direct impact on interfaces. This also applies to 0 and 1 changes, which may require an update to input screens or help screens or both. on applications Level 0 changes should have no to minimum impact on applications. Higher changes will normally have an impact on applications, although the impact for applications sending the message may be different from the impact for applications receiving the message. Some changes may apply to message types that are to be implemented in a User Group (). Users that are not registered in the cannot send or receive messages of these message types. The impact on any application depends directly on the need or desire to support these message types. 20 July

8 5 When a change description is not clear without further explanation, a brief business context is sometimes provided to help the readers better understand the reasoning behind the change. Changes that were modified for implementation last year are indicated in blue font. 5.1 Category 0 FIN System s There are no changes planned yet for this category for implementation in SR Other Technical Changes The following changes are tentatively scheduled for implementation in SR New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. Header block 3 Header block 3 CR No Make field 121 (Unique End-to-end Transaction Reference (UETR)) optional in header block 3 of enquiry and cancellation messages in categories 1, 2, and 9. To have the full community benefitting from the change in SR 2018 that required all SWIFT users to be able to receive field 121 (and field 111) in all category 1 and category 2 messages. Adding field 121 will help to unambiguously identify the associated payment message for enquiries and cancellations. Allowing field 121 on category 9 messages potentially impacts all users on receiving side, but opens up possibilities to directly engage between ordering and beneficiary bank (without requiring RMA). CR No Make use of payment credit confirmation (with field 121 Unique End-to-end Transaction Reference (UETR) in header block 3 and structure in field 79 as defined within the SWIFT gpi service) optional for any SWIFT user. To allow non-gpi members to also send a structured payment processing status message. Only if non-gpi members send the message in scope of the SWIFT gpi service (meaning the receiver is the SWIFT gpi Tracker, TRCKCHZZ, and user header block field 121 is present) validation against the mandatory structure as defined in the SWIFT gpi service will be triggered on the network and the SWIFT gpi Tracker status will be updated. 20 July

9 5.3 Category 1 Customer Payments and Cheques The following changes are tentatively scheduled for implementation in SR New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 101 MT 102 MT 102 STP REMIT MT 110 MT 102 MT 102 STP REMIT STP MT 104 MT 107 MT 110 MT 190 MT 191 MT 192 MT 195 MT 196 MT 199 CR Yes Except Mandate a country code in fields 50F and 59F. The move towards format option F is not creating the expected MT 110 improvement in regulatory reporting. Many local regulations require country to be present and also in both the Wolfsberg Group and FATF recommendations, country code is needed for the originator and best practice for the beneficiary. CR Yes Except Remove code word REC in field 72 to increase STP. Preference is given to really stop the use through network validation. Use of code word REC in field 72 is almost always stopping STP. This STP can be avoided by using proper bilaterally agreed code words or replacing it with INT or ACC when relevant. MT 110 CR No Make field 121 (Unique End-to-end Transaction Reference (UETR)) optional in header block 3 of enquiry and cancellation messages in categories 1, 2, and 9. To have the full community benefitting from the change in SR 2018 that required all SWIFT users to be able to receive field 121 (and field 111) in all category 1 and category 2 messages. Adding field 121 will help to unambiguously identify the associated payment message for enquiries and cancellations. Allowing field 121 on category 9 messages potentially impacts all users on receiving side, but opens up possibilities to directly engage between ordering and beneficiary bank (without requiring RMA). MT 199 CR No Make use of payment credit confirmation (with field 121 Unique End-to-end Transaction Reference (UETR) in header block 3 and structure in field 79 as defined within the SWIFT gpi service) optional for any SWIFT user. To allow non-gpi members to also send a structured payment processing status message. Only if non-gpi members send the message in scope of the SWIFT gpi service (meaning the receiver is the SWIFT gpi Tracker, TRCKCHZZ, and user header block field 121 is present) validation against the mandatory structure as defined in the SWIFT gpi service will be triggered on the network and the SWIFT gpi Tracker status will be updated. 20 July

10 MT 101 MT 102 MT 102 STP MT 110 MT 101 MT 102 MT 102 STP REMIT STP MT 110 CR Yes Except Limit the number of lines to indicate name in fields 50F and 59F. To reduce interoperability issues (potential data truncation or wrong MT 110 mapping) and to align with the High Value Payment usage of ISO messages, where a name can be maximum 66 characters. CR Yes Except Extend use of free format options in fields 50 and 59 until the end of the coexistence period between MT and MX messages. The intention of the agreed free format removal in SR 2020 was to STP move towards more structure in the format option F, but the structure needed in format option F is limited and seems to lead to truncation MT 110 issues. ISO messages offer a more granular structure for postal addresses. Moving towards ISO is preferred, without the intermediary step to move to format option F in MT. Additionally, the industry take up of format option F is still very low, which means it is unlikely the industry will be ready by SR 2020 for a full free format removal. 20 July

11 5.4 Category 2 Financial Institution Transfers The following changes are tentatively scheduled for implementation in SR New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 202 COV MT 205 COV MT 210 MT 200 MT 201 MT 202 MT 202 COV MT 203 MT 204 MT 205 MT 292 MT 295 MT 296 MT 299 MT 202 COV MT 205 COV MT 210 MT 202 COV MT 205 COV MT 210 CR No Mandate a country code in fields 50F and 59F. The move towards format option F is not creating the expected improvement in regulatory reporting. Many local regulations require country to be present and also in both the Wolfsberg Group and FATF recommendations, country code is needed for the originator and best practice for the beneficiary. CR No Except Remove code word REC in field 72 to increase STP. Preference is given to really stop the use through network validation. MT 204 Use of code word REC in field 72 is almost always stopping STP. This can be avoided by using proper bilaterally agreed code words or replacing it with INT or ACC when relevant. CR No Make field 121 (Unique End-to-end Transaction Reference (UETR)) optional in header block 3 of enquiry and cancellation messages in categories 1, 2, and 9. To have the full community benefitting from the change in SR 2018 that required all SWIFT users to be able to receive field 121 (and field 111) in all category 1 and category 2 messages. Adding field 121 will help to unambiguously identify the associated payment message for enquiries and cancellations. Allowing field 121 on category 9 messages potentially impacts all users on receiving side, but opens up possibilities to directly engage between ordering and beneficiary bank (without requiring RMA). CR No Limit the number of lines to indicate name in fields 50F and 59F. To reduce interoperability issues (potential data truncation or wrong mapping) and to align with the High Value Payment usage of ISO messages, where a name can be maximum 66 characters. CR No Extend use of free format options in fields 50 and 59 until the end of the coexistence period between MT and MX messages. The intention of the agreed free format removal in SR 2020 was to move towards more structure in the format option F, but the structure needed in format option F is limited and seems to lead to truncation issues. ISO messages offer a more granular structure for postal addresses. Moving towards ISO is preferred, without the intermediary step to move to format option F in MT. Additionally, the industry take up of format option F is still very low, which means it is unlikely the industry will be ready by SR 2020 for a full free format removal. 20 July

12 5.5 Category 3 Foreign Exchange, Money Markets, and Derivatives The following changes are tentatively scheduled for implementation in SR Change requests postponed from SR 2018 MT 300 MT 304 MT 300 MT 304 CR Yes Except Remove free format options and update code lists in settlement party fields. MT 300 To improve message straight-through-processing and automated matching. CR Yes Except Remove free format options and update code lists in trade party fields. MT 300 To improve message straight-through-processing and automated matching. New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 300 CR No Add optional fields for post-trade events, such as early-delivery, early-termination and roll-over. Provide standardised support for business practices that are common in Asian countries. MT 300 CR No Add additional optional data fields related to post-trade events (supplement of CR 1461). Provide additional standardised support for business practices that are common in Asian countries. MT 300 MT 304 MT 305 MT 306 MT 340 MT 341 MT 360 MT 361 CR No Except Change reporting jurisdiction code for Russian Federation in field 22L. MT 304 Central Bank of Russian Federation now regulates Russian market. MT 304 CR Yes Add codes to field 22A to indicate that the message was a copy. To be able to identify messages copied to third parties, for example to a fund administrator. 20 July

13 MT 304 CR Yes MT 300 MT 304 MT 305 MT 306 MT 320 MT 321 MT 330 MT 340 MT 341 MT 360 MT 361 MT 380 MT 381 Allow a BIC to be specified in option J of fields 5x and 8x. Add validation of clearing codes in option J of fields 5x and 8x. Reduce the impact of CR 1309 and CR 1310 party field changes on the custodian community. CR No Except Update field 39M to specify usage of the settlement centre for all offshore-settled trades. MT 304 Clarify that Hong Kong should not be assumed to be the default for offshore Renminbi. MT 321 MT 380 MT July

14 5.6 Category 4 Collections and Cash Letters The following changes are tentatively scheduled for implementation in SR New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. New New message for Pre-advice of Documentary Collection. There is currently no SWIFT FIN message type that can be used by a Remitting Bank to advise the Collecting/Presenting bank that they will be receiving a Documentary Collection from the Remitting bank. 3? 20 July

15 5.7 Category 5 Securities Markets The following changes are tentatively scheduled for implementation in SR on all category 5 messages There are no changes requested impacting all MTs in this category for implementation in SR Trade Initiation and Confirmation MTs 502, 509, 513, 514, 515, 517, 518, 528, 529, 576, 584 (alignment in other messages possible) New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 502 MT 509 MT 513 MT 514 MT 515 MT 517 MT 518 MT 576 CR No Add a new format option to qualifier TRRF in field 20C of subsequence Linkages to allow 52 characters. Transport the Unique Transaction Identifier (UTI) in Trade Initiation and Confirmation (TIC) and Settlement and Reconciliation (S&R) messages. MT 502 CR No Add a code for Buy-in indicator when qualifier SETR is used in field 22F of subsequence Settlement Details. CSDR proposes to adopt a Buy-in mechanism in case of fail delivery of fail instrument. The new trade must carry a reference to the original trade and be specified to this new Buy-in. MT 514 MT 515 MT 518 CR No Add a research fee qualifier RSCH in field 17B of subsequence Amounts. Clarification requested by community on how to refer in field 17B to the qualifier RSCH in field 19A of subsequence Amounts in MT 54X messages, which was introduced in SR July

16 5.7.3 Settlement and Reconciliation MTs 508, 524, 535-8, 540-9, 578, 586 (alignment in other messages possible) New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 535 CR No Add a new field for Holdings Narrative in sequence C. Add a new code for Quarterly Statements indicator when qualifier SFRE is used without Data Source Scheme in field 22F for sequence A. Add a qualifier for Security Interest, Lien or Right of Set-Off in field17b of Sequence A. Article 63 of the MiFID II regulation must be followed. MT 537 CR No Addition of a Penalty/Penalty Redistribution sequence in the MT 537 (Statement of Pending Transactions). CSDs will implement a penalty mechanism for settlement fails which will serve as an effective deterrent for participants that cause settlement fails. The penalties information needs to be transported. MT 535 MT 536 MT 537 MT 540 MT 541 MT 542 MT 543 MT 544 MT 545 MT 546 MT 547 MT 548 MT 540 MT 541 MT 542 MT 543 MT 544 MT 545 MT 546 MT 547 MT 548 MT 549 CR No Add a new format option to qualifier TRRF in field 20C of subsequence Linkages to allow 52 characters. Transport the Unique Transaction Identifier (UTI) in Trade Initiation and Confirmation (TIC) and Settlement and Reconciliation (S&R) messages. CR No Add a code for Buy-in indicator when qualifier SETR is used in field 22F of subsequence Settlement Details. CSDR proposes to adopt a Buy-in mechanism in case of fail delivery of fail instrument. The new trade must carry a reference to the original trade and be specified to this new Buy-in. 20 July

17 MT 548 CR No Add a Penalty/Penalty Redistribution sequence. Add a Penalties function of the message to field 23G of sequence A. CSDs will implement a penalty mechanism for settlement fails which will serve as an effective deterrent for participants that cause settlement fails. The penalties information needs to be transported. MT 541 MT 543 MT 545 MT 547 CR No Add a research fee qualifier RSCH in field 17B of subsequence Amounts. Clarification requested by community on how to refer in field 17B to the qualifier RSCH in field 19A of subsequence Amounts in MT 54X messages, which was introduced in SR Corporate Action MTs 564, 565, 566, 567, 568 (alignment in other messages possible) New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 564 MT 565 CR No Add field 95L with qualifier ISSU in sequence B, E, and subsequence E1 of MT 564. Add field 95L with qualifier OFFO in sequence D of MT 564. Add field 95L with qualifier ALTE in subsequence B2 of MT 565. Add field 95L with qualifier ALTE in sequence C of MT 565. To allow institutional investors to report an event with the LEI (Legal Entity Identifier) of the issuer and to allow institutional investors to communicate their own LEI to its custodian or broker. MT 565 MT 567 CR No Add 6 new qualifiers (CNDA, CNDB, CNDC, CNDD, CNDE, and CNDF) to field 17B in sequence D of MT 565 and in sequence B of MT 567. To enable securities holders to give explicit acknowledgement that specific certification conditions on voluntary offers are fulfilled. MT 566 CR No Delete qualifier CERT in field 17B in sequence C of MT 566. The presence of a Certification / Breakdown flag at confirmation stage does not make sense. 20 July

18 MT 564 MT 566 CR No Add qualifier CONT with code values ACTU and CONT in field 22a in subsequence E1 of MT 564 and subsequence D1 of MT 566. Modify definition of qualifier CONT and code value ACTU in field 22a in subsequence E2 of MT 564. Add code value CONT in field 22a in subsequence E2 of MT 564. Modify name and definition of qualifier CONT in field 22a in subsequence D2 of MT 566. To harmonise the semantic of the Contractual Payment Indicator between MT 564 and MT 566 and enable its usage for securities proceeds payments. MT 565 MT 567 CR No Add qualifier RDUQ in field 36a in sequence D of MT 565. Add code IRDQ to qualifier REJT in field 24B in subsequence A2a in MT 567. To enable CSD participants to indicate the additional quantity of new shares which must be added to the number of shares calculated by the CSD based on the exercised rights provided by its participants on the Securities option with Buy Up disposition of fraction. This applies as well for exercise of warrants and conversion of bonds. MT 564 MT 566 CR No Add qualifiers DEDI, DEFP, DEIT, and DERY in field 19B in subsequence E2 of MT 564 and in subsequence D2 of MT 566. To enable the account servicer to communicate the cash amounts components corresponding to the four deemed rate type codes defined for the Deemed Rate that may be used for Tax On Non-Distributed Proceeds event as specified in the AU tax law amendment for attribution managed investment trust (AMIT). MT 567 CR No Add codes DQBI and DQBV to qualifier REJT in field 24B in subsequence A2a in MT 567. To be able to report specific rejection reasons for invalid bid price or bid increment present in instructions on events with bidding ranges such as Dutch auction events. MT 564 MT 565 MT 567 CR No Add code ACOD to qualifier OPTF in field 22F in sequence E in MT 564. Add code ALLC to qualifier ALTE in field 95a in sequence C of MT 565. Add rejection reason code ACOD to qualifier REJT in field 24B in subsequence A2a in MT 567. To enable agents/offerors to identify certain holders that have been given preferential rights when participating in voluntary reorganisation events such as offers or are used to identify certain holders participating in these events. These preferential rights may not be subject to proration or having a proration applied at a different rate. The identification is needed as these holders are participating in a separate offer occurring within the market, such as a public offering of other securities. 20 July

19 MT 564 MT 565 MT 566 CR No Add optional code SUOV to qualifier CAOP in field 22F in sequence E of MT 564, in sequence D of MT 565 and in sequence D of MT 566. Add qualifier QOVE to field 36a in sequence D in MT 565. Add network validated rule on qualifier QOVE and option code SUOV in MT 565. Add qualifier OSUB in field 19B in subsequence D2 in MT 566. To enable oversubscriptions to an event as a feature of the option as mandated in the US market per the over-subscription processing rule. This will allow the depository to process rights subscription events with an over- subscription privilege within a single option. MT 566 CR No MT 564 MT 566 MT 565 MT 567 MT 564 MT 566 Add qualifiers ADJS and REFU in fields 19B in subsequence D2. To enable the agent to communicate an adjustment to a subscription amount after the final rate of the rights offer has been fixed and to report also the part of the original subscription amount that must be refunded in case of pro-ration of the oversubscription. CR No Move qualifier OSUB from field 90a in sequence E to subsequence E2 in MT 564 and from field 90a in sequence D in MT 566 to subsequence D2 in MT 566. To better link the oversubscription price with the subscription price (generic price paid per product) at the cash movement instead of the option. CR No Add qualifier OPTF with code value OPLF in field 22a in sequence D of MT 565 and in sequence B of MT 567. To enable the securities holders to notify the depository that particular instructions should be treated as an odd-lot (for example that instructions should not be pro-rated if pro-ration were to occur). CR No Modify the definition of the Conversion Type Indicator qualifier CONV in field 22F in sequence D of MT 564 and sequence C of MT 566. To align the semantic of the conversion type indicator in the standard with the new SMPG market practice defined on rolling/ongoing events Collateral Management MTs , 527, 558, 569 (alignment in other messages possible) There are no changes requested impacting this (sub)category for implementation in SR Other Category 5 changes There are no changes requested impacting this (sub)category for implementation in SR July

20 5.8 Category 6 Commodities and Reference Data The following changes are tentatively scheduled for implementation in SR New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 600 MT 601 CR No Change reporting jurisdiction code for Russian Federation in field 22L. Central Bank of Russian Federation now regulates Russian market. 20 July

21 5.9 Category 7 Documentary Credits and Guarantees/Standby Letters of Credit The following changes are tentatively scheduled for implementation in SR Change requests postponed from SR 2018 MT 760 CR No Redesigned MT 760 Guarantee/Standby Letter of Credit. The MT 760 was a free format message and, over the years, the community has asked for this message to be completely redesigned to provide structured fields, for better automation, STP, limit controls, etc. MT 767 CR No Redesigned MT 767 Guarantee/Standby Letter of Credit Amendment. The MT 767 Amendment needed to be completely redesigned, given the redesign of the base message MT 760. MT 760 CR No Create a new message Demand Guarantee/Standby Letter of Credit Issuance Extension. This message is sent in addition to an MT 760 Guarantee/Standby Letter of Credit message, when the information in the undertaking exceeds the maximum message size of the MT 760. This message may specify the terms and conditions of the undertaking and for a counter-undertaking and may specify the requested terms and conditions of the local undertaking. Up to eight MT 761 messages may be sent in addition to the MT 760. MT 768 MT 769 CR No Add new field, File Identification, to identify location of attachments. For guarantees and standbys, there is often a need to transmit other documents (letter of guarantee, cover letter, etc.), these can be sent by another channel, but a reference is needed in the message. This new field is the same as the one present in the MT 798 trade messages for corporate to bank communication. MT 760 CR No Add a new field for the counter-guarantee rules. Only one field is present in the MT for the undertaking rules. There is no field for counter-undertaking rules in case they are different. MT 760 CR No Add an optional field for Transfer Conditions. To have a separate field for Transfer Conditions instead of putting it in field 77U with all terms and conditions. 20 July

22 MT 768 MT 769 MT 768 MT 769 MT 768 MT 769 CR No Use z character set in all charges fields and change the field letter option where necessary. The X character set lacks some commonly used characters for example &. Current workarounds are not satisfactory. CR No Change field 72 to 72Z to allow the use of the z character set. The x character set lacks some commonly used characters for example &. Current workarounds are not satisfactory. CR No Change format of party fields which identify banks. Name and address fields are too short and need to be increased to 6 lines. Prefixes are also needed to identify name, address and country lines. Automatic extraction of country code is needed for compliance reasons. New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 707 MT 708 CR No Introduce code word MODIFY for fields 45, 46, 47. This change request will benefit large retail clients that have internal order systems that send their banks files with large number of goods details and only want to modify part of the details. MT 760 CR No Rename field 44H Governing Law to include Place of Jurisdiction. To enable specifying the governing law and place of jurisdiction (which is as important as the governing law in some countries). MT 767 CR No MT 760 MT 767 Add new fields for Delivery of amended undertaking and Delivery To / Collection By. To align MT 767 with the redesign of MT 760 for delivery of the amendment to the undertaking. CR No Move field 23X File identification to sequence A. To clarify that field 23X can be used for the undertaking or counterundertaking. MT 768 CR No Remove codes for beneficiary acceptance or rejection from field 72Z. Beneficiary acceptance or rejection must not be communicated by MT 768 but rather by MT July

23 5.10 Category 8 Travellers Cheques There are no changes requested impacting this category for implementation in SR July

24 5.11 Category 9 Cash Management and Customer Status The following changes are tentatively scheduled for implementation in SR New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT 992 MT 995 MT 996 CR No Make field 121 (Unique End-to-end Transaction Reference (UETR)) optional in header block 3 of enquiry and cancellation messages in categories 1, 2, and 9. To have the full community benefitting from the change in SR 2018 that required all SWIFT users to be able to receive field 121 (and field 111) in all category 1 and category 2 messages. Adding field 121 will help to unambiguously identify the associated payment message for enquiries and cancellations. Allowing field 121 on category 9 messages potentially impacts all users on receiving side, but opens up possibilities to directly engage between ordering and beneficiary bank (without requiring RMA). MT 910 CR No Mandate a country code in fields 50F and 59F. The move towards format option F is not creating the expected improvement in regulatory reporting. Many local regulations require country to be present and also in both the Wolfsberg Group and FATF recommendations, country code is needed for the originator and best practice for the beneficiary. MT 910 CR No Limit the number of lines to indicate name in fields 50F and 59F. To reduce interoperability issues (potential data truncation or wrong mapping) and to align with the High Value Payment usage of ISO messages, where a name can be maximum 66 characters. MT 910 CR No Extend use of free format options in fields 50 and 59 until the end of the coexistence period between MT and MX messages. The intention of the agreed free format removal in SR 2020 was to move towards more structure in the format option F, but the structure needed in format option F is limited and seems to lead to truncation issues. ISO messages offer a more granular structure for postal addresses. Moving towards ISO is preferred, without the intermediary step to move to format option F in MT. Additionally, the industry take up of format option F is still very low, which means it is unlikely the industry will be ready by SR 2020 for a full free format removal. 20 July

25 5.12 Category n Common Group s The following changes are tentatively scheduled for implementation in SR New change requests for SR 2019 These requests must still be validated by a maintenance working group and can be subject to modification or rejection. MT n92 CR No Add optional code words to field 79 to indicate cancellation reason. To cover cancellation reasons identified by participant banks in the gpi Stop and Recall service and to align further with ISO cancellation codes. MT n92 CR No Add a usage rule to indicate willingness to indemnify in field 79. In a cancellation request there is potentially a need to add the willingness to indemnify on top of the cancellation reason. A guideline for this usage was overlooked in SR Adding a usage rule can help aligning market practice on this. The gpi Stop and Recall service has already incorporated this. 20 July

26 Legal Notices Legal Notices Copyright SWIFT All rights reserved. Disclaimer This publication constitutes advance information only and is not to be considered the final and complete standards documentation for the subject matter published herein. The information in this publication may change from time to time. You must always refer to the latest available version. SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR Policy - End-User License Agreement, available at > About Us > Legal > IPR Policies > SWIFT Standards IPR Policy. Translations The English version of SWIFT documentation is the only official and binding 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, 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. 20 July