Updated High-Level Information

Transcription

1 This document is an updated version of the High-Level Information document that was published on on 20 July All the expected or requested changes described in that document were validated by a maintenance working group and were either approved or rejected. Country user groups voted on the approved requests and the Board must ratify those that were accepted. This document describes the outcome of the maintenance working groups and the results of the country voting. It 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. 16 November 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 Change Requests Postponed to a Later Standards Release Rejected Change Requests Withdrawn Change Requests Legal Notices November

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 provide the SWIFT community with an update to the initial high- information that was published in July 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. After the MWG review of the change requests, user group chairpersons of all countries were invited to discuss in their user group the change requests, accepted by the MWG, and to vote on the acceptance or rejection of these individual change requests in their community. The SWIFT Banking and Services (BSC) Board committee 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 16 November

4 Introduction 1 Introduction Important This document describes changes that have been validated by a maintenance working group (MWG) and approved by Banking and Services (BSC) Board committee. The changes have been accepted by country user group votes and the Board will ratify the voting results at its December 2018 meeting. 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 12 months before the standards 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 a guide for implementers, a note has been added to each change request to indicate whether a change is mandatory or optional. Each institution must assess their own applications and business needs when implementing these changes. 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. 16 November

5 Schedule for SR Schedule for SR 2019 The timeline below describes the schedule for development and implementation of SR SR 2019 Timeline This publication provides details of the changes that are approved by the country voting Important process. While this provides a good overview of all the expected changes for the next release, the only official source for information about a Standards MT Release is the Standards Release Guide that is published in December. 16 November

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, optional fields or sequences 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. 16 November

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. 16 November

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 are implemented differently from the original request are indicated in a blue font. As a guide for implementers, a note has been added, in red, to each change request to indicate whether a change is mandatory or optional for users that are sending the messages. All users must be able to receive messages with the changes. The change request numbers (CR 000nnn) are present to enable the submitters to easily track their requests. 5.1 Category 0 FIN System s The following changes are scheduled for implementation in SR NEW Service message SWIFT introduces a new service message to support FIN Session graceful shut-down for maintenance purpose. The service message will be emitted by the FIN system to the relevant connected customers FIN interfaces to notify it to initiate graceful shutdown of the opened FIN session. This new service message includes reference to the Logical terminal and the FIN session number, in addition to other required parameters enabling the graceful shut-down execution. The message is optional and will only be sent when the flag in the interface is enabled at log in. By default the flag will be set to "false". 3 NA 5.2 Other Technical Changes The following changes are scheduled for implementation in SR 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). This field is optional for outbound messages. 16 November

9 Block 3 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. This message is optional for outbound messages. 16 November

10 5.3 Category 1 Customer Payments and Cheques The following changes are scheduled for implementation in SR MT 101 MT 102 MT 102 STP MT 103 MT 103 REMIT MT 110 MT 190 MT 191 MT 192 MT 195 MT 196 MT 199 CR No Except Mandate a country code in fields 50F and 59F. MT 101 The move towards format option F is not creating the expected MT 102 improvement in regulatory reporting. Many local regulations require country to be present and also in both the Wolfsberg Group and FATF MT 103 recommendations, country code is needed for the originator and best REMIT practice for the beneficiary. Change will be implemented in SR MT 102 STP This change is mandatory if format option F is used in outbound messages and requires structured underlying customer data (with country information) in payments systems. 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). This field is optional for outbound messages. 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. This message is optional for outbound messages. MT 101 MT 102 MT 102 STP MT 103 MT 110 CR Yes Except Limit the number of lines to indicate name in fields 50F and 59F. MT 103 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. Change will be implemented in SR This change is mandatory if format option F is used in outbound messages. 16 November

11 MT 103 MT 103 REMIT MT 110 CR No Except Remove code word REC in field 72 to increase STP. MT 103 Use of code word REC in field 72 is almost always stopping STP. This REMIT can be avoided by using proper bilaterally agreed code words or replacing it with INT or ACC when relevant. The payments maintenance working group agreed to stop promoting the use of this code on a global. Use will nevertheless still be possible on a bilaterally agreed. In the Reference Guides, there will be a documentation change to remove the code word REC, but this will have no validation impact as the code word is still allowed (if bilaterally agreed). This change only impacts documentation, not validation. MT 101 MT 102 MT 102 STP MT 103 MT 103 REMIT MT 103 STP MT 110 CR Yes Except Extend use of free format options in fields 50 and 59 until the end of the coexistence period between MTs and MXs. MT 103 MT 103 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. Structuring customer data in banks is needed. Banks must invest to make sure they have underlying structured customer data in their systems. There is no need to update back-office systems for MT standards, but investment must start to have correct, structured data available when migrating to ISO This change has no impact on users for SR 2019, but preparation work to facilitate ISO migration is recommended. 16 November

12 5.4 Category 2 Financial Institution Transfers The following changes are scheduled for implementation in SR MT 202 COV MT 205 COV MT 210 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. Change will be implemented in SR This change is mandatory if format option F is used in outbound messages and requires structured underlying customer data (with country information) in payments systems. MT 292 MT 295 MT 296 MT 299 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). This field is optional for outbound messages. MT 202 COV MT 205 COV MT 210 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. Change will be implemented in SR This change is mandatory if format option F is used in outbound messages. MT 200 MT 201 MT 202 MT 202 COV MT 203 MT 204 MT 205 CR No Except Remove code word REC in field 72 to increase STP. 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. The payments maintenance working group agreed to stop promoting the use of this code on a global. Use will nevertheless still be possible on a bilaterally agreed. In the Reference Guides, there will be a documentation change to remove the code word REC, but this will have no validation impact as the code word is still allowed (if bilaterally agreed). This change only impacts documentation, not validation. 16 November

13 MT 202 COV MT 205 COV MT 210 CR No Extend use of free format options in fields 50 and 59 until the end of the coexistence period between MTs and MXs. 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. Structuring customer data in banks is needed. Banks must invest to make sure they have underlying structure customer data in their systems. There is no need to update back-office systems for MT standards, but investment must start to have correct, structured data available when migrating to ISO This change has no impact on users for SR 2019, but preparation work to facilitate ISO migration is recommended. 16 November

14 5.5 Category 3 Foreign Exchange, Money Markets, and Derivatives The following changes are scheduled for implementation in SR 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. This change was updated due to CR This CR will have a mandatory impact on many users of these message types, as certain field options will no-longer be allowed and new codes will be created. 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. This change was updated due to CR This CR will have a mandatory impact on many users of these message types, as certain field options will no-longer be allowed and new codes will be created. 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. The new fields will be added as an additional sequence F at the end of the message. This sequence is optional for outbound messages. 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 the Russian market. Code "BankOfRussia" will be added to indicate Central Bank of Russian Federation and replaces FFMS. This change impacts users that want to include regulatory reporting information relating to Russia. The code is not validated. 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. Implementation will be in MT 304 only and will be by adding three new codes (CAMN, CCAN, CNEW) to field 22A. These codes are optional for outbound messages. 16 November

15 MT 300 MT 304 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 CR Yes Except 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. MT 300 Reduce the impact of CR 1309 and CR 1310 party field changes on the custodian community. Implementation will be to MT 300 as well as MT 304. The following 2 specific changes were agreed: 1) To validate that if code CLRC is present in option J, it must be followed by a 2 character clearing system code. 2) To slightly alter the proposed validation of the ABIC code in option J, so that it cannot be present by itself, but can be present with any other code (and not necessarily LEIC). This change is mandatory and must be implemented when format option J is used. CR No Clarify correct usage of payment clearing centre field Except Clarify that Hong Kong should not be assumed to be the default for offshore Renminbi. This is a documentation change to field 77H that does not impact the message structure. MT 304 MT 321 MT 380 MT November

16 5.6 Category 4 Collections and Cash Letters There are no changes scheduled for implementation in SR November

17 5.7 Category 5 Securities Markets The following changes are scheduled for implementation in SR on all category 5 messages There are no changes scheduled 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) 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. Any institution that uses TIC and S&R messages, like brokers, custodians, etc. can optionally use the new format option in outbound 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. This change is optional for outbound messages and will be used by investment managers when needed in the context of CSDR. 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 This change is optional for outbound messages and will be used by investment firms that will have to report under MIFIDII regulation. 16 November

18 5.7.3 Settlement and Reconciliation MTs 508, 524, 535-8, 540-9, 578, 586 (alignment in other messages possible) 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 field 17B of sequence A. Article 63 of the MiFID II regulation must be followed. This change is optional for outbound messages and will be used by investment firms that hold client financial instruments or client funds and have to report under MIFIDII regulation. 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. This change is optional for outbound messages for institutions that are impacted by CSDR like settlement platforms, trading venues, CCPS, CSDs and all their participants and their clients. 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. Any institution that uses TIC and S&R messages, like brokers, custodians, etc. can optionally use the new format option in outbound 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. This change is optional for outbound messages and will be used by investment managers when needed in the context of CSDR. 16 November

19 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. This change is optional for outbound messages for institutions that are impacted by CSDR like settlement platforms, trading venues, CCPS, CSDs and all their participants and their clients. 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 This change is optional for outbound messages and will be used by investment firms that will have to report under MIFIDII regulation. MTs 564, 565, 566, 567, 568 (alignment in other messages possible) MT 564 MT 565 MT 567 CR No Add code SHAR (Shareholder Number) to qualifier OPTF in field 22F in sequence E in MT 564. Add optional and repeatable field 20D Reference with qualifier SHAR to sequence D of MT 565. Add rejection reason code SHAR 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. The MWG has decided to reuse the existing qualifier SHAR (Shareholder Number) in field 20C Reference and to insert it into the sequence D of the MT 565 (Corporate Action Instruction). The MWG also agreed to name the new Option Features code in the MT 564 as "SHAR" (Shareholder Number) and to use the same code name SHAR (Shareholder Number Missing) for the rejection reason code in the MT 567. This change is optional for outbound messages. 16 November

20 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. The change is mandatory but no impact is expected on FIN users. MT 564 MT 565 CR No Add qualifier ISSU (Issuer), OFFO (Offeror), and TAGT (Transfer Agent) in field 95a Party in sequence F in MT 564 with format options L, P, Q, R. Add new format option L to field 95a Party on qualifier OWND and make it repeatable in sequence C of MT 565 and add new network validated rule on OWND in 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 The MWG agreed with the following implementation details: In the MT 564, in sequence F, add a new format option L (for LEI) to the :95a: Party field add a new optional and non-repeatable "Issuer" (qualifier ISSU) field and a new optional and non-repeatable "Transfer Agent" field (with the existing TAGT code), and a new optional and repeatable "Offeror" (Qualifier OFFO) field all with format options P, Q, R, L; Transfer Agent (TAGT) will have the following definition: "A trust company, bank, or similar financial institution appointed by a Fund Management Company to maintain records of investors and account balances. The transfer agent records transactions, including subscriptions, redemptions, switches, transfers, and re-registrations". Add also the LEI format option L to the Issuer Agent (ISAG) Party. In the MT 565, In sequence C, add format option L (for LEI) to the :95a: Party field and make Beneficial Owner Identification (OWND) qualifier repeatable and add the format option L to OWND (in addition to P,R,V); Add a new network validated rule on the OWND qualifier to restrict the presence of :95L::OWND to a single occurrence with either :95P::OWND or :95R::OWND or :95V::OWND so that the current restrictions on the usage of OWND do not change by making it repeatable. This change is optional for outbound messages. CR No Add qualifier RDUQ in field 36a in sequence D of MT 565. Add new network validated rule on RDUQ in 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. This change is optional for outbound messages. 16 November

21 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). This change is optional for outbound messages. 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. This change is optional for outbound messages. MT 566 CR No 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. This change is optional for outbound messages. MT 565 MT 567 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). This change is optional for outbound messages. MT 564 MT 566 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. The MWG decided to additionally rename the CONV qualifier as "Event Sequence Type Indicator" and agreed on the following amended definitions: CONV: Specifies whether the event is an interim or a final event in a series of predefined or planned events of the same type and for the same underlying instrument. FINL: This is the final event in a series of successive events. INTE: This is an interim event in a series of successive events. This is a change of definition and does not impact the message structure. 16 November

22 5.7.5 Collateral Management There are no changes scheduled for implementation in SR Other Category 5 changes The following message showed less than one live message per day sent over the network over the past 24 months and is accepted to be deleted in SR 2019: MT 559 Paying Agent's Claim 16 November

23 5.8 Category 6 Commodities and Reference Data The following changes are scheduled for implementation in SR MT 600 MT 601 CR No Change reporting jurisdiction code for Russian Federation in field 22L. Central Bank of Russian Federation now regulates the Russian market. This change impacts users that want to include regulatory reporting information relating to Russia. The code is not validated. 16 November

24 5.9 Category 7 Documentary Credits and Guarantees/Standby Letters of Credit The following changes are scheduled for implementation in SR NEW CR No Create a new message (MT 765 Guarantee/SBLC Demand). This message is sent by a party (as the beneficiary or on behalf of the beneficiary) to a party which has issued an undertaking (guarantee, demand guarantee, or standby letter of credit or dependent undertaking), either directly or via a third party. It is used to demand payment under an undertaking and may include a request to extend the expiry date. The demand itself must be specified as narrative text within the message. It may indicate availability of supporting documentation in addition to the demand. All users must be able to receive this message if they are active participants in Trade Finance. NEW CR No Create a new message (MT 775 Demand Guarantee/SBLC Amendment Extension). This message is sent in addition to an MT 767, when the information in the undertaking would otherwise exceed the maximum message size of the MT 767. This message may specify the terms and conditions of the undertaking and for a counter-undertaking may specify the requested terms and conditions of the local undertaking Up to 8 MTs 775 may be sent in addition to the MT 767. All users must be able to receive this message if they are active participants in Trade Finance. NEW CR No Create a new message (MT 785 Guarantee/SBLC Non Extension Notification). This message is sent in one of two ways: 1) by the party that issued the undertaking (guarantee, demand guarantee, or standby letter of credit or dependent undertaking) to the beneficiary (that is, only in case of beneficiary being a financial institution) or to a nominated advising party that advised the undertaking to the beneficiary or to another advising party 2) by the party that issued the counter-undertaking (counterguarantee or counter-standby) to the beneficiary of the counter-undertaking (financial institution) It is used to notify the beneficiary, if applicable, via one or more advising parties of the non-extension of the referenced undertaking beyond the current expiry date. All users must be able to receive this message if they are active participants in Trade Finance. 16 November

25 NEW CR No Create a new message (MT 786 Guarantee/SBLC Demand Refusal). This message is sent by the party that issued the undertaking (guarantee, demand guarantee, or standby letter of credit or dependent undertaking) to a bank as the beneficiary or to the presenter of the demand, either directly or via a third party. It is used by the party obligated on the undertaking and to whom a demand for payment has been made, to notify the beneficiary that the demand has been refused. The reason(s) giving cause for refusal must be specified as narrative text within the message. All users must be able to receive this message if they are active participants in Trade Finance. NEW CR No Create a new message (MT 787 Guarantee/SBLC Amendment Response). This message is sent in one of two ways: 1) by the beneficiary when the beneficiary is a financial institution 2) by a nominated advising party that advised the undertaking amendment to the beneficiary or advised the undertaking amendment to another advising party It is sent to the bank that issued the undertaking amendment (guarantee, demand guarantee, or standby letter of credit or dependent undertaking), either directly or via one or more advising parties, to indicate acceptance or rejection by the beneficiary of the amendment. All users must be able to receive this message if they are active participants in Trade Finance. NEW 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, 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 MTs 761 may be sent in addition to the MT 760. All users must be able to receive this message if they are active participants in Trade Finance. 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. All users must be able to receive this message if they are active participants in Trade Finance. 16 November

26 MT 767 CR No Redesigned MT 767 Guarantee/Standby Letter of Credit Amendment. MT 768 MT 769 The MT 767 Amendment needed to be completely redesigned, given the redesign of the base message MT 760. Senders will be impacted if they wish to amend MT 760 fields that are now added to the MT 767. The free format field must not be used when a specific field is available for the amendment. Receivers of the MT 707 must be able to accept and process messages that contain these changes. 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. This change is optional for outbound messages. 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 This change is optional for outbound messages. MT 767 CR No 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. Senders will be impacted if they wish to amend MT 760 fields that are now added to the MT 767. The free format field must not be used when a specific field is available for the amendment. Receivers of the MT 707 must be able to accept and process messages that contain these changes. MT 760 MT 767 CR No Move field 23X File identification to sequence A. To clarify that field 23X can be used for the undertaking or counterundertaking. This impacts all users as the MT 760 and MT 767 are redesigned. 16 November

27 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 787. Sender should use MT 787 instead of codes in Acknowledgement. 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. This change is optional for outbound messages (senders). Receivers must be able to accept and process messages that contain the z character set. MT 768 MT 769 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. This change is optional for senders. Receivers must be able to accept and process messages that contain the z character set. 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). This is a change of definition and does not impact the message structure. 16 November

28 5.10 Category 8 Travellers Cheques The following messages showed less than one live message per day sent over the network over the past 24 months and are accepted to be deleted in SR 2019: MT T/C Sales and Settlement Advice [Single] MT T/C Inventory Destruction/Cancellation Notice 16 November

29 5.11 Category 9 Cash Management and Customer Status The following changes are scheduled for implementation in SR MT 910 CR No Extend use of free format options in fields 50 and 59 until the end of the coexistence period between MTs and MXs. 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. Structuring customer data in banks is needed. Banks must invest to make sure they have underlying structure customer data in their systems. There is no need to update back-office systems for MT standards, but investment must start to have correct, structured data available when migrating to ISO This change has no impact on users for SR 2019, but preparation work to facilitate ISO migration is recommended. 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. Change will be implemented in SR This change is mandatory if format option F is used in outbound messages. 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. Change will be implemented in SR This change is mandatory if format option F is used in outbound messages and requires structured underlying customer data (with country information) in payments systems. 16 November

30 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). This field is optional for outbound messages. 16 November

31 5.12 Category n Common Group s The following changes are scheduled for implementation in SR 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. These codes are optional for outbound messages. 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. This change is optional for outbound messages. 16 November

32 Change Requests Postponed to a Later Standards Release 6 Change Requests Postponed to a Later Standards Release The changes in this section are held over for a future release. The release will be decided at a later date. 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. 16 November

33 Rejected Change Requests 7 Rejected Change Requests These changes were rejected by a maintenance working group. NEW CR NA 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. MT 564 MT 566 CR No Add a new optional and non-repeatable element Contractual Payment Indicator in the Cash Movement Details sequence in seev.031/cano message. To harmonise the semantic of the Contractual Payment Indicator between MT 564 and MT 566 and enable its usage for securities proceeds payments. The MWG has rejected the UK change request on the MTs but has agreed to the SWIFT recommendation to add the missing contractual payment indicator into the seev.031 Notification message so as to ensure full alignment of the notification and coexistence between ISO and ISO MT 564 MT 565 MT 566 seev.031 seev.033 seev.035 seev.036 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 564 MT 566 seev.031 seev.035 seev.036 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. MT 565 MT 567 seev.033 seev.034 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. 16 November

34 Withdrawn Change Requests 8 Withdrawn Change Requests These changes were withdrawn by the submitter. 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. 16 November

35 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. 16 November