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

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 BIC 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, Syndications, and Reference Data Category 7 Documentary Credits and Guarantees 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 the change requests in their user group and to 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 17 November

4 Introduction 1 Introduction Important This document describes changes that have been validated by a maintenance working group and approved by Board business committees. The changes have been accepted by country user group votes and the Board will ratify the voting results at its December 2017 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 2018 (SR 2018). 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 2018 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 2018, which SWIFT will publish in December 2017, will fully describe SR Approved changes will be effective as of 18 November 2018, 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. 17 November

5 Schedule for SR Schedule for SR 2018 The timeline below describes the schedule for development and implementation of SR SR 2018 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. 17 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. 17 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. 17 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 MT 097 CR Remove field 434. This field was designed and reserved for sanctions screening, but was not implemented on the network. This change is mandatory, but will have no impact on FIN users. 5.2 Other Technical Changes The following changes are scheduled for implementation in SR Header Block 3 CR No Except Be able to receive field 111 (Service Type Identifier) and field 121 (Unique End-to-End Transaction Reference (UETR)) in header MT 101 block 3. These two fields are used in the SWIFT global payment innovation (SWIFT gpi) service that allows banks in the SWIFT gpi Closed User Group (CUG) to track payments based on a UETR. As of November 2017, members of SWIFT gpi will be able to include the header fields in MT 102 MT 104 MT 105 MT 107 all MTs 103 that they send, also to banks that are not in the CUG. The SWIFT gpi service is expanding in terms of MTs included in the service in which they also need to include field 111 and field 121 in header block 3. To avoid different requests per SWIFT gpi service expansion, it is beneficial to have the capability to receive the fields in the header block 3 for all category 1 and category 2 messages. For inbound messages, all users must to be able to receive these header fields. For outbound messages, all users are impacted by CR 1338, CR 1339 and/or CR 1340, which make it mandatory to also send or forward field 121 but only in the MTs mentioned in those CRs. Non SWIFT gpi banks may never send or forward field November

9 Header Block 3 CR No Except Mandate to populate (where not already done so) or pass on, field 121 (Unique End-to-End Transaction Reference (UETR)) in header block 3 of all MTs 103, MTs 103 REMIT, MTs 103 STP. REMIT To provide SWIFT gpi banks and their corporates with real time visibility of where a transaction is, while on the SWIFT network. Header Block 3 This change is mandatory and is expected to have an important impact on back-office systems. NOTE: FIN Interface providers must automatically generate a UETR if this is not already provided on the outgoing message. CR No Mandate to populate (where not already done so) or pass on, field 121 (Unique End-to-End Transaction Reference (UETR)) in header block 3 of all MTs 202 COV and MTs 205 COV. To provide SWIFT gpi banks and their corporates with real time visibility of where a transaction is, while on the SWIFT network. Header Block 3 This change is mandatory and is expected to have an important impact on back-office systems. NOTE: FIN Interface providers must automatically generate a UETR if this is not already provided on the outgoing message. CR No Mandate to populate (where not already done so) or pass on, field 121 (Unique End-to-End Transaction Reference (UETR)) in header block 3 of all MTs 202 and MTs 205. To provide SWIFT gpi banks with real time visibility of where a transaction is, while on the SWIFT network. Header Block 3 This change is mandatory and is expected to have an important impact on back-office systems. NOTE: FIN Interface providers must automatically generate a UETR if this is not already provided on the outgoing message. CR No Update definition of code NOK in field 433. To indicate that it is also possible that the message was auto released by the service. Header Block 3 This is a definition change with minimal impact. CR No Add field 434 with the new name Payment Controls Information for Receiver to header block 3. To provide information to the receiver from the Payments Control Service about the screened message. This change will only impact Payments Control users. 17 November

10 Header Block 3 CR No Add field 434 to the list of header block 3 fields that do not allow characters CR and Lf. To align with the other fields in the header block 3. Header Block 3 This is an alignment with minimal impact. CR No Modify the description of field 433. To indicate that the screening service provides information to the receiver of the screened message. Error codes This is a definition change with minimal impact. CR No Update definitions of Status error codes to refer to any SWIFT screening service instead of only the Sanctions Screening service. To allow generic use of error codes, in field 431, that indicate message status as they will also be used by the Payments Control service. Error codes This is a definition change with minimal impact. CR No Update definition of the Abort Reasons error code S1 to refer to any SWIFT screening service instead of only the Sanctions Screening service. To allow generic use of error codes that indicate the abort reason as they will also be used by the payments control service. 5.3 BIC changes This is a definition change with minimal impact. The ISO 9362 Business Identifier Code (BIC) standard was revised in A transition period started in January 2015 and will end in November All users must carefully plan and budget for systems or process changes, if any, to be prepared on time. All details of implementation changes and impact of the revised ISO 9362 BIC standard can be found in the information paper: A summary of what has changed: BIC owners are responsible for the maintenance of the data related to their BICs and must keep it up-to-date and confirm the accuracy at least once a year The SWIFTRef BIC Plus directory contains enriched data and replaces BIC directory that will be decommissioned in November 2018 After 18 November 2018, SWIFT will no longer issue BICs with "1" in position 8 After 18 November 2018, a change of connectivity status will no longer systematically imply the expiry and creation of a new BIC A summary of what has NOT changed: Existing connected and non-connected BICs are not changed 17 November

11 Structure of the BIC is not changed There will always be connected and non-connected BICs 5.4 Category 1 Customer Payments and Cheques The following changes are scheduled for implementation in SR IMPORTANT NOTE In messages that contain customer fields, a structured format option (letter F) is now available for ordering customer (50F) and beneficiary customer (59F). The free format options for these customer fields will be removed in SR 2020, the impacted fields and messages are as follows: 50H MT K MT 102, MT 102 STP,, REMIT, STP 59 (no letter option) MT 101, MT 102, MT 102 STP,, REMIT, STP (See also sections 5.5 and 5.12 for other impacted messages) Users are urged to plan for this change well in advance of SR Cat 1 CR No Except Be able to receive field 111 (Service Type Identifier) and field 121 (Unique End-to-End Transaction Reference (UETR)) in header MT 101 block 3. These two fields are used in the SWIFT global payment innovation (SWIFT gpi) service that allows banks in the SWIFT gpi Closed User Group (CUG) to track payments based on a UETR. As of November 2017, members of SWIFT gpi will be able to include the header fields in MT 102 MT 104 MT 105 MT 107 all MTs 103 that they send, also to banks that are not in the CUG. The SWIFT gpi service is expanding in terms of MTs included in the service in which they also need to include field 111 and field 121 in header block 3. To avoid different requests per SWIFT gpi service expansion, it is beneficial to have the capability to receive the fields in the header block 3 for all category 1 and category 2 messages. REMIT STP For inbound messages, all users must to be able to receive these header fields. For outbound messages, all users are impacted by CR 1338, CR 1339, and/or CR 1340, which make it mandatory to also send or forward field 121 but only in the MTs mentioned in those CRs. Non SWIFT gpi banks may never send or forward field 111. CR No Except Mandate to populate (where not already done so) or pass on, field 121 (Unique End-to-End Transaction Reference (UETR)) in header block 3. REMIT To provide SWIFT gpi banks and their corporates with real time visibility of where a transaction is, while on the SWIFT network. This change is mandatory and is expected to have a significant impact on back-office systems. 17 November

12 MT 101 MT 102 MT 102 STP REMIT STP MT 110 CR No Except Add a usage guideline for use of Chinese commercial codes (CCC) in MT payment messages and refer to the published CCC MT 101 conversion table. MT 102 To standardise conversion of Chinese characters between CNAPS and FIN messages, because the FIN character set does not allow for the use of Chinese characters. This change impacts users that have bilaterally agreed to include Chinese characters in MTs. REMIT 5.5 Category 2 Financial Institution Transfers The following changes are scheduled for implementation in SR IMPORTANT NOTE In messages that contain customer fields, a structured format option (letter F) is now available for ordering customer (50F) and beneficiary customer (59F). The free format options for these customer fields will be removed in SR 2020, the impacted fields and messages are as follows: 50 (no letter option) MT K MT 202 COV, MT 205 COV 59 (no letter option) MT 202 COV, MT 205 COV (See also sections 5.4 and 5.12 for other impacted messages) Users are urged to plan for this change well in advance of SR Cat 2 CR No Except Be able to receive field 111 (Service Type Identifier) and field 121 (Unique End-to-End Transaction Reference (UETR)) in header MT 204 block 3. These two fields are used in the SWIFT global payment innovation (SWIFT gpi) service that allows banks in the SWIFT gpi Closed User Group (CUG) to track payments based on a UETR. As of November 2017, members of SWIFT gpi will be able to include the header fields in all MTs 103 that they send, also to banks that are not in the CUG. The SWIFT gpi service is expanding in terms of MTs included in the service in which they also need to include field 111 and field 121 in header block 3. To avoid different requests per SWIFT gpi service expansion, it is beneficial to have the capability to receive the fields in the header block 3 for all category 1 and category 2 messages. For inbound messages, all users must to be able to receive these header fields. For outbound messages, all users are impacted by CR 1338, CR 1339, and/or CR 1340, which make it mandatory to also send or forward field 121 but only in the MTs mentioned in those CRs. Non SWIFT gpi banks may never send or forward field November

13 MT 202 COV MT 205 COV CR No Mandate to populate (where not already done so) or pass on, field 121 (Unique End-to-End Transaction Reference (UETR)) in header block 3. To provide SWIFT gpi banks and their corporates with real time visibility of where a transaction is, while on the SWIFT network. This change is mandatory and is expected to have a significant impact on back-office systems. MT 202 MT 205 CR No Mandate to populate (where not already done so) or pass on, field 121 (Unique End-to-End Transaction Reference (UETR)) in header block 3. To provide SWIFT gpi banks with real time visibility of where a transaction is, while on the SWIFT network. This change is mandatory and is expected to have a significant impact on back-office systems. MT 202 MT 202 COV MT 203 MT 205 MT 205 COV MT 210 CR No Add a usage guideline for use of Chinese commercial codes (CCC) in MT payment messages and refer to the published CCC conversion table. To standardise conversion of Chinese characters between CNAPS and FIN messages, because the FIN character set does not allow for the use of Chinese characters. This change impacts users that have bilaterally agreed to include Chinese characters in MTs. 17 November

14 5.6 Category 3 Foreign Exchange, Money Markets, and Derivatives The following changes are scheduled for implementation in SR MT 300 MT 304 MT 305 MT 306 MT 320 MT 330 MT 340 MT 360 MT 361 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 No Except Add MiFID II client reporting field. MT 304 To support MiFID II Delegated Act article 59 client reporting. It was agreed to add a repetitive optional field to indicate commission and fees. This field is optional for outbound messages. CR No Except Add field for place of settlement. MT 304 To avoid use of free format fields to indicate place of settlement for MT 321 offshore trades such as CNY that is settled in Hong Kong. MT 380 MT 381 This field is optional for outbound messages. MT 304 CR Yes MT 300 MT 304 MT 305 MT 306 MT 340 Change conditionality of commission and fees fields. To allow for inclusion of commission and fees even where other accounting information is not present. It was agreed to make the existing, mandatory data elements optional within sequence D. The fields are optional for outbound messages. CR No Except Update message usage rules. MT 304 To clarify that a FIN confirmation message cannot create a legal agreement between the parties. This change is a documentation clarification and is expected to have no technical implementation impact. 17 November

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

16 5.8 Category 5 Securities Markets The following changes are scheduled for implementation in SR 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 513 MT 514 MT 515 MT 518 CR No Add a research fee qualifier to field 19A. To comply with MiFID II, which requires more transparency on research fees. The group decided to implement qualifier RSCH (aligned with FIX and Omgeo) and not RFEE as initially requested. This change is optional for outbound messages Settlement and Reconciliation MTs 508, 524, 535-8, 540-9, 578, 586 (alignment in other messages possible) MT 536 MT 537 MT 540 MT 541 MT 542 MT 543 MT 544 MT 545 MT 546 MT 547 MT 548 MT 578 MT 586 MT 508 MT 536 MT 537 MT 538 CR No Add codes SWIF (switch from) and SWIT (switch to) to the qualifier SETR in field 22F. To enable users to indicate the settlement of switch orders. This change is optional for outbound messages. CR No Add code TAXD for tax debit events, to qualifier CAEV, in field 22F. Add also a new optional and non-repetitive deemed payment rate qualifier DEEM and deemed payment amount qualifier DEEM in field 92a. To be able to report to non-resident investors about a withholding tax on deemed income originating from Attribution Managed Investment Trusts (AMIT) as covered in the new tax law amendment bill The deemed income is attributed to the unit holder without being actually distributed. 17 November

17 A single solution was adopted for both CR 1300 and CR 1317, which is to add new code TNDP (Tax on Non-Distributed Proceeds) to qualifier CAEV in field 22F of sequence A, to add a new optional qualifier TNDP in field 22F in sequence D and to add also a new optional and repetitive deemed rate qualifier DEEM in field 92a and a new optional deemed amount qualifier DEEM in field 19B. New corporate action event created with new optional field qualifiers. Implementation of these new qualifiers is mandatory if the new Tax on Non Distributed Proceeds event is supported by the local market practice or when a service agreement (SLA) exists between the sender and the receiver. MT 508 MT 536 MT 537 MT 538 CR No Add an even type code TXEV, for tax events, add an optional nonrepetitive indicator qualifier TXEV to field 22F and add a network validation rule to control the presence of these two elements. Add also a new and non-repetitive gross taxable amount qualifier GRTX to field 19B. To be able to report to investors about a withholding tax on deemed dividend distributions related to convertible securities as covered in the section 305(c ) US regulation and a withholding tax on dividend equivalent payment related to equity-linked derivative instruments as covered in the section 871(m) US regulation. A single solution was adopted for both CR 1300 and CR 1317, which is to add new code TNDP (Tax on Non-Distributed Proceeds) to qualifier CAEV in field 22F of sequence A, to add a new optional qualifier TNDP in field 22F in sequence D and to add also a new optional and repetitive deemed rate qualifier DEEM in field 92a and a new optional deemed amount qualifier DEEM in field 19B. New corporate action event created with new optional field qualifiers. Implementation of these new qualifiers is mandatory if the new Tax on Non Distributed Proceeds event is supported by the local market practice or when a service agreement (SLA) exists between the sender and the receiver. MT 540 MT 541 MT 542 MT 543 MT 544 MT 545 MT 546 MT 547 CR No Add a research fee qualifier to field 19A. To comply with MiFID II, which requires more transparency on research fees. The group decided to implement qualifier RSCH (aligned with FIX and Omgeo) and not RFEE as initially requested. This change is optional for outbound messages Corporate Action MTs 564, 565, 566, 567, 568 (alignment in other messages possible) MT 564 CR No Add a new network validated rule which applies to the stock lending deadline qualifier BORD. To remove inconsistencies in the number of occurrences that are allowed for some of the format options. This fully aligns the restrictions that are applied in ISO and ISO November

18 This change is mandatory and must be implemented in markets where the Stock Lending Deadline Date/Time element is used. MT 564 MT 566 CR No Add new network validated rules which apply to qualifiers TAXR and WITL. To remove inconsistencies in the number of occurrences of TXAR and WITL that are allowed for some of the format options. This change is mandatory and must be implemented when qualifier TAXR and WITL are used. MT 564 MT 566 CR No Add a rate type code CDFI (Conduit Foreign Income) to qualifiers GRSS and NETT in field 92a and add an optional, non-repetitive qualifier CDFI to field 19B. To be able to report to the investor within the frame of distribution of income events, the exact nature of an income when it originates from a foreign source and which is subject to different tax treatments as per the investor resident status. This change is optional for outbound messages and is primarily intended for income events in the Australian market. MT 564 MT 566 MT 568 CR No Add code TAXD for tax debit events, to qualifier CAEV, in field 22F. Add also a new optional and non-repetitive deemed payment rate qualifier DEEM and deemed payment amount qualifier DEEM in field 92a. To be able to report to non-resident investors about a withholding tax on deemed income originating from Attribution Managed Investment Trusts (AMIT) as covered in the new tax law amendment bill The deemed income is attributed to the unit holder without being actually distributed. A single solution was adopted for both CR 1300 and CR 1317, which is to add new code TNDP (Tax on Non-Distributed Proceeds) to qualifier CAEV in field 22F of sequence A, to add a new optional qualifier TNDP in field 22F in sequence D and to add also a new optional and repetitive deemed rate qualifier DEEM in field 92a and a new optional deemed amount qualifier DEEM in field 19B. New corporate action event created with new optional field qualifiers. Implementation of these new qualifiers is mandatory if the new Tax on Non Distributed Proceeds event is supported by the local market practice or when a service agreement (SLA) exists between the sender and the receiver. 17 November

19 MT 564 CR No Modify the usage rule on the declared rate qualifier DEVI in field 92a. To be able to announce the declared rate via the DEVI qualifier even when that currency and rate is one of the many currency options offered for the event. This is a documentation change that does not impact the message structure. MT 564 MT 567 CR No Add three optional and non-repeatable price qualifiers to field 90a, add a network validated rule to control the presence of these qualifiers together with :22F::OPTF//QCAS. Add an optional and non-repeatable amount qualifier STAC to field 19B as well as a new network validated rule to enforce a choice between the status quantity and the status cash amount. To enable full STP for instructions on cash amount that was introduced earlier in SR 2017 as some associated amounts were missing. The change is mandatory for inbound and outbound messages when instructions with an instructed amount are allowed by market practice or service agreement (SLA) between the sender and the receiver. MT 564 MT 566 MT 568 CR No Add an even type code TXEV, for tax events, add an optional nonrepetitive indicator qualifier TXEV to field 22F, and add a network validation rule to control the presence of these two elements. Add also a new and non-repetitive gross taxable amount qualifier GRTX to field 19B. To be able to report to investors about a withholding tax on deemed dividend distributions related to convertible securities as covered in the section 305(c ) US regulation and a withholding tax on dividend equivalent payment related to equity-linked derivative instruments as covered in the section 871(m) US regulation. A single solution was adopted for both CR 1300 and CR 1317, which is to add new code TNDP (Tax on Non-Distributed Proceeds) to qualifier CAEV in field 22F of sequence A, to add a new optional qualifier TNDP in field 22F in sequence D and to add also a new optional and repetitive deemed rate qualifier DEEM in field 92a and a new optional deemed amount qualifier DEEM in field 19B. New corporate action event created with new optional field qualifiers. Implementation of these new qualifiers is mandatory if the new Tax on Non Distributed Proceeds event is supported by the local market practice or when a service agreement (SLA) exists between the sender and the receiver. MT 564 MT 566 CR No Delete the non-resident rate qualifier NRES from field 92a. Delete the three rate type codes IMPU, PREC and TIER from qualifier TAXC in field 92a. To clean-up the unused tax related rates and rate type codes. The change is mandatory but no impact is expected on FIN users. 17 November

20 MT 564 MT 566 CR No Modify the definition of the certification deadline qualifier CERT in field 98. To enlarge the scope of the certification deadline beyond the simple declaration of beneficial ownership. This is a change of definition of an optional field which does not impact the message structure Collateral Management There are no changes scheduled for implementation in SR Other Category 5 changes MT 575 CR Yes Add codes SWIF (switch from) and SWIT (switch to) to the qualifier SETR in field 22F. To enable users to indicate the settlement of switch orders. This change is optional for outbound messages. MT 575 CR Yes Add code TAXD for tax debit events, to qualifier CAEV, in field 22F. Add also a new optional and non-repetitive deemed payment rate qualifier DEEM and deemed payment amount qualifier DEEM in field 92a. To be able to report to non-resident investors about a withholding tax on deemed income originating from Attribution Managed Investment Trusts (AMIT) as covered in the new tax law amendment bill The deemed income is attributed to the unit holder without being actually distributed. A single solution was adopted for both CR 1300 and CR 1317, which is to add new code TNDP (Tax on Non-Distributed Proceeds) to qualifier CAEV in field 22F of sequence A, to add a new optional qualifier TNDP in field 22F in sequence D and to add also a new optional and repetitive deemed rate qualifier DEEM in field 92a and a new optional deemed amount qualifier DEEM in field 19B. New corporate action event created with new optional field qualifiers. Implementation of these new qualifiers is mandatory if the new Tax on Non Distributed Proceeds event is supported by the local market practice or when a service agreement (SLA) exists between the sender and the receiver. 17 November

21 MT 575 CR Yes Add an even type code TXEV, for tax events, add an optional nonrepetitive indicator qualifier TXEV to field 22F and add a network validation rule to control the presence of these two elements. Add also a new and non-repetitive gross taxable amount qualifier GRTX to field 19B. To be able to report to investors about a withholding tax on deemed dividend distributions related to convertible securities as covered in the section 305(c ) US regulation and a withholding tax on dividend equivalent payment related to equity-linked derivative instruments as covered in the section 871(m) US regulation. A single solution was adopted for both CR 1300 and CR 1317, which is to add new code TNDP (Tax on Non-Distributed Proceeds) to qualifier CAEV in field 22F of sequence A, to add a new optional qualifier TNDP in field 22F in sequence D and to add also a new optional and repetitive deemed rate qualifier DEEM in field 92a and a new optional deemed amount qualifier DEEM in field 19B. New corporate action event created with new optional field qualifiers. Implementation of these new qualifiers is mandatory if the new Tax on Non Distributed Proceeds event is supported by the local market practice or when a service agreement (SLA) exists between the sender and the receiver. 17 November

22 5.9 Category 6 Commodities, Syndications, and Reference Data The following changes are scheduled for implementation in SR MT 600 MT 601 CR No Update message usage rules. To clarify that a FIN confirmation message cannot create a legal agreement between the parties. This change is a documentation clarification and is expected to have no technical implementation impact. MT 600 MT 601 CR No Add MiFID II client reporting field. To support MiFID II Delegated Act article 59 client reporting. It was agreed to add a repetitive optional field to indicate commission and fees. This field is optional for outbound messages. 17 November

23 5.10 Category 7 Documentary Credits and Guarantees The following changes are scheduled for implementation in SR New MT 744 CR No Create a new message (MT 744 Notice of Non-Conforming Reimbursement Claim). This message is sent by the reimbursing bank to the bank claiming reimbursement. It is used to notify the Receiver that the Sender considers the claim, on the face of it, as not to be in accordance with the instruction in the reimbursement authorisation for the reason(s) as stated in this message. The Sender also provides the Receiver with details regarding the disposal of the claim. All users must be able to receive this message if they are active participants in Trade Finance. New MT 759 CR No Create a new message (MT 759 Ancillary Trade Structured ). This message is sent to request or to provide information, such as a fraud alert or a financing request, concerning an existing trade transaction such as a documentary credit, demand guarantee, standby letter of credit, or an undertaking (for example, a guarantee, surety, etc.). All users must be able to receive this message if they are active participants in Trade Finance. MT 707 CR No Redesigned MT 707. The MT 707 has been completely redesigned to be a mirror image of the MT 700 Issue of a Documentary Credit. This way, any field present in the MT 700 can be amended using the MT 707. Codes have been added to specify which changes are being made in free format fields. All users must be able to receive this message if they are active participants in Trade Finance. New MT 708 CR No Create new extension message MT 708. The redesign of the MT 707 calls for a new extension message, which is this MT 708. All users must be able to receive this message if they are active participants in Trade Finance. 17 November

24 MT 707 CR No Full alignment of MT 707 with updated MT 700 (SR 2018 version), so that all changes can be done in specific, structured fields. Same business rationale as for the redesigned MT 707 planned for SR It will allow and enforce use of structured fields for amendments instead of free text. Senders will be impacted if they wish to amend MT 700 fields that are now added to the MT 707. 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 756 CR No Add a free format text field in MT 756 as it is in MT 752 (SR 2018 version). There is not enough space in field 72Z for all details related to the reimbursement or payment conditions. This change is optional for senders. Receivers of the MT 756 must be able to accept and process messages that contain the new field. MT 700 MT 701 MT 710 MT 711 MT 720 MT 721 CR No Add two new fields: Special Payment Instructions for Beneficiary/Receiving Bank. These two fields will provide a place for information that is now put in other free format fields. The first field specifies special payment conditions applicable to the beneficiary, for example, post-financing request/conditions for beneficiary. The second field specifies special payment conditions applicable to the receiving bank, for example, postfinancing request/conditions for receiving bank only. This change is optional for senders. Receivers must be able to accept and process messages that contain the new fields. MT 700 MT 710 MT 720 CR No Add new field for Requested Confirmation Party after field 49 Confirmation Instructions. In some scenarios, it is not always clear which bank is requested to add its confirmation, this field is therefore required to specify it. This change is optional for senders. Receivers must be able to accept and process messages that contain the new field. MT 707 CR No Add field 45B, 46B, and 47B as optional fields in MT 707, and add Sequence Of Total, so that multiple MTs 707 can be sent for one amendment. As part of an amendment, allow full replacement text to be provided for the fields 45B Description of Goods and/or Services, 46B Documents Required and 47B Additional Conditions. This change is optional for senders. Receivers must be able to accept and process messages that contain the new fields. 17 November

25 MT 730 MT 752 CR No Add field 79 to MT 730 and MT 752. To accommodate information that does not fit in the structured fields of this message. This change is optional for senders. Receivers must be able to accept and process messages that contain the new field. MT 707 CR No Add field 50 Changed Applicant Details in new MT 707. This change relates to the new MT 707 that is part of SR This will allow the sender to communicate changes to the name or address of the applicant (for example, in case of merger). This change is optional for senders. Receivers must be able to accept and process messages that contain the new field. MT 700 MT 705 MT 710 MT 720 MT 740 MT 747 CR No Remove field 39B Maximum Credit Amount, which contains only one code NOT EXCEEDING. This change relates to the updated MT 700 and related messages. This code does not seem to make any difference, being present or not. This is a mandatory change with no expected business impact. MT 700 MT 710 MT 720 MT 730 MT 740 MT 742 MT 750 MT 752 MT 754 MT 700 MT 701 MT 705 MT 710 MT 711 MT 720 MT 721 MT 700 MT 705 MT 707 MT 710 MT 720 MT 730 MT 732 MT 740 MT 742 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 senders. Receivers must be able to accept and process messages that contain the z character set. CR No Use z character set in field 45A, 46A and 47A. 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. 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. 17 November

26 MT 747 MT 750 MT 752 MT 754 MT 756 MT 700 MT 705 MT 710 MT 720 CR No Delete all codes that relate to revocable documentary credits from field 40A. In practice, revocable instruments no longer exist. These codes are therefore obsolete and must be removed. This is a mandatory change, but is expected to have no business impact. MT 700 MT 710 MT 720 CR No Change the format of field 43P and introduce codes. To make the field more precise and more structured, allowing for automation. This field is optional for senders. Receivers must be able to accept and process messages that contain this field. MT 700 MT 710 MT 720 CR No Change the format of field 43T and introduce codes. To make the field more precise and more structured, and to allow for automation. This field is optional for senders. Receivers must be able to accept and process messages that contain this field. MT 700 MT 710 MT 720 CR No Change format and definition of field 48. To make the field more precise and more structured, and to allow for automation. This field is optional for senders. Receivers must be able to accept and process messages that contain this field. MT 734 MT 750 MT 754 CR No Use z character set in fields 77J and 77A. 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. 17 November

27 MT 734 MT 750 MT 754 CR No Change field 73 to 73A 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 700 MT 701 MT 710 MT 711 MT 720 MT 721 CR No Change usage rule in fields 45a, 46a, and 47a. The rule about the number of occurrences of these fields is too restrictive and many institutions are forced to bypass it, as this is not a network-validated rule. This change aligns the usage rule with the market practice. This changes is mandatory, but is expected to have minimal business impact. MT 700 MT 701 MT 710 MT 711 MT 720 MT 721 CR No Change usage rule about number of continuation messages. The limit of three continuation messages is too low and many institutions send more than three, as this is not a network-validated rule. This change aligns the usage rule with the market practice. This changes is mandatory, but is expected to have minimal business impact. MT 700 MT 710 MT 720 CR No Change definition in field 49. To clarify the definition. This is a documentation change that does not impact the message structure. MT 700 MT 710 MT 720 CR No Rename field 48 Period for Presentation to "Period for Presentation in days". To align field name and format change. This change is optional for senders. Receivers must be able to accept and process messages that contain the z character set. MT 700 MT 710 MT 720 MT 740 CR No Rename field 42P Deferred Payment Details to "Negotiation/Deferred Payment Details". To clarify the field name as the field can also be used for negotiation details. This is a documentation change that does not impact the message structure. 17 November

28 MT 700 CR No Delete some usage rules about freely negotiable documentary credits. These sentences are out of scope of the SWIFT messages because it is not related to the correct usage and transmission of documentary credits information on the SWIFT network. This is a documentation change that does not impact the message structure. 17 November

29 5.11 Category 8 Travellers Cheques There are no changes scheduled for implementation in SR November

30 5.12 Category 9 Cash Management and Customer Status The following changes are scheduled for implementation in SR IMPORTANT NOTE In messages that contain customer fields, a structured format option (letter F) is now available for ordering customer (50F) and beneficiary customer (59F). The free format options for these customer fields will be removed in SR 2020, the impacted fields and messages are as follows: 50K MT 910 (See also sections 5.4 and 5.5 for other impacted messages) Users are urged to plan for this change well in advance of SR MT 910 CR No Add a usage guideline for use of Chinese commercial codes (CCC) in MT payment messages and refer to the published CCC conversion table. To standardise conversion of Chinese characters between CNAPS and FIN messages, because the FIN character set does not allow for the use of Chinese characters. This change impacts users that have bilaterally agreed to include Chinese characters in MTs. 17 November

31 5.13 Category n Common Group s The following changes are scheduled for implementation in SR MT n98 CR No Change the character set for field 77E in the MT n98. This change is required to include interbank trade messages starting from SR 2018 (as they will contain z characters). This change is optional and has no direct impact on existing agreements between present users of the MT n98. Any changes to existing agreements must be agreed by all parties to the agreement. MT n92 CR No Add optional cancellation reason codes to field 79. To introduce structured codes that enable a consistent understanding and alignment with ISO 20022, to reduce ambiguity and to allow code word based prioritised workflow. These codes are optional for outbound messages. MT n96 CR No Add optional response and reason codes to field 76. To introduce different structured codes that enable a consistent understanding and alignment with ISO 20022, to reduce ambiguity and to allow code word based prioritised workflow. These codes are optional for outbound messages. 17 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 SR 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, 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. 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 Add a new field in MT 760 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 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 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. 17 November

33 Change Requests Postponed to a Later Standards Release MT 300 MT 304 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 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 760 CR No Add an optional field for Transfer Conditions. This change relates to the new MT 760 that is part of SR MT 768 MT 769 Change is optional for the sender. 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 768 MT 769 CR No Use z character set in field 72. The X character set lacks some commonly used characters for example &. Current workarounds are not satisfactory. MT 768 MT 769 CR No Use z character set in all charges fields. The X character set lacks some commonly used characters for example &. Current workarounds are not satisfactory. MT 768 MT 769 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. 17 November