Updated High-Level Information

Updated High-Level Information

Updated High-Level Information

Standards MT November 2018 Updated High-Level Information This document is an updated version of the High-Level Information document that was published on www.swift.com on 20 July 2017. 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

Standards MT November 2018 Updated High-Level Information Table of Contents 17 November 2017 2 Table of Contents Preface . . 3 1 Introduction . . 4 2 Schedule for SR 2018 . . 5 3 Impact Levels of the Change Requests . . 6 4 Evaluation of the Impact on Interfaces and Applications . . 7 5 Overview of Changes per Category . . 8 5.1 Category 0 – FIN System Messages . . 8 5.2 Other Technical Changes . . 8 5.3 BIC changes . . 10 5.4 Category 1 – Customer Payments and Cheques . . 11 5.5 Category 2 – Financial Institution Transfers . . 12 5.6 Category 3 – Foreign Exchange, Money Markets, and Derivatives .

. 14 5.7 Category 4 – Collections and Cash Letters . . 15 5.8 Category 5 – Securities Markets . . 16 5.9 Category 6 – Commodities, Syndications, and Reference Data . . 22 5.10 Category 7 – Documentary Credits and Guarantees . . 23 5.11 Category 8 – Travellers Cheques . . 29 5.12 Category 9 – Cash Management and Customer Status . . 30 5.13 Category n – Common Group Messages . . 31 6 Change Requests Postponed to a Later Standards Release . . 32 7 Rejected Change Requests . . 34 8 Withdrawn Change Requests . . 37 Legal Notices . . 38

Standards MT November 2018 Updated High-Level Information Preface 17 November 2017 3 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-level information that was published in July 2017. 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

Standards MT November 2018 Updated High-Level Information Introduction 17 November 2017 4 1 Introduction This document describes changes that have been validated by a maintenance working Important 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 Updated High-Level Information 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 2018. 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.

Standards MT November 2018 Updated High-Level Information Schedule for SR 2018 17 November 2017 5 2 Schedule for SR 2018 The timeline below describes the schedule for development and implementation of SR 2018. 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.

Standards MT November 2018 Updated High-Level Information Impact Levels of the Change Requests 17 November 2017 6 3 Impact 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 levels Level 0 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.

Level 1 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+ An existing message type is removed from the network Level 2- 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. Level 2+ The message layout or the FIN validation or both are significantly impacted, for example, optional fields or sequences are added or deleted.

Level 3- A new message type is created for use in a message user group (MUG) or the use of an existing message type is changed from use in a MUG to general use, that is, all users must be able to receive and process the new message. Level 3 A new message type is created for general use, that is, all users must be able to receive and process the new message.

Standards MT November 2018 Updated High-Level Information Evaluation of the Impact on Interfaces and Applications 17 November 2017 7 4 Evaluation of the Impact on Interfaces and Applications Impact on interfaces All changes can have a direct impact on interfaces.

This also applies to level 0 and level 1 changes, which may require an update to input screens or help screens or both. Impact on applications Level 0 changes should have no to minimum impact on applications. Higher level 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 Message User Group (MUG). Users that are not registered in the MUG 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 8 5 Overview of Changes per Category 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 Messages The following changes are scheduled for implementation in SR 2018. Message Types (MT) Short description of the modification Impact level MUG MT 097 CR 001364 2- 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 2018. Message Types (MT) Short description of the modification Impact level MUG Header Block 3 CR 001337 2+ No Except MT 101 MT 102 MT 104 MT 105 MT 107 Be able to receive field 111 (Service Type Identifier) and field 121 (Unique End-to-End Transaction Reference (UETR)) in header 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 111.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 9 Message Types (MT) Short description of the modification Impact level MUG Header Block 3 CR 001338 2+ No Except MT 103 REMIT 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. 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 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. Header Block 3 CR 001339 2+ 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. 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.

Header Block 3 CR 001340 2+ 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. 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. Header Block 3 CR 001365 1 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. This is a definition change with minimal impact. Header Block 3 CR 001366 1 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 10 Message Types (MT) Short description of the modification Impact level MUG Header Block 3 CR 001367 1 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. This is an alignment with minimal impact. Header Block 3 CR 001368 1 No Modify the description of field 433. To indicate that the screening service provides information to the receiver of the screened message.

This is a definition change with minimal impact.

Error codes CR 001404 1 No Update definitions of Message Status error codes 31-38 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. This is a definition change with minimal impact. Error codes CR 001405 1 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. This is a definition change with minimal impact. 5.3 BIC changes The ISO 9362 Business Identifier Code (BIC) standard was revised in 2014. A transition period started in January 2015 and will end in November 2018. 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

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 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 2018. 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 101 50K MT 102, MT 102 STP, MT 103, MT 103 REMIT, MT 103 STP 59 (no letter option) MT 101, MT 102, MT 102 STP, MT 103, MT 103 REMIT, MT 103 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 2020.

Message Types (MT) Short description of the modification Impact level MUG Cat 1 CR 001337 2+ No Except MT 101 MT 102 MT 104 MT 105 MT 107 Be able to receive field 111 (Service Type Identifier) and field 121 (Unique End-to-End Transaction Reference (UETR)) in header 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 111. MT 103 MT 103 REMIT MT 103 STP CR 001338 2+ No Except MT 103 REMIT 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 12 Message Types (MT) Short description of the modification Impact level MUG MT 101 MT 102 MT 102 STP MT 103 MT 103 MT 103 REMIT MT 103 STP MT 110 CR 001302 1 No Except MT 101 MT 102 MT 103 REMIT 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. 5.5 Category 2 – Financial Institution Transfers The following changes are scheduled for implementation in SR 2018. 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 210 50K 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 2020.

Message Types (MT) Short description of the modification Impact level MUG Cat 2 CR 001337 2+ No Except MT 204 Be able to receive field 111 (Service Type Identifier) and field 121 (Unique End-to-End Transaction Reference (UETR)) in header 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 111.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 13 Message Types (MT) Short description of the modification Impact level MUG MT 202 COV MT 205 COV CR 001339 2+ 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 001340 2+ 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 001302 1 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 14 5.6 Category 3 – Foreign Exchange, Money Markets, and Derivatives The following changes are scheduled for implementation in SR 2018. Message Types (MT) Short description of the modification Impact level MUG MT 300 MT 304 MT 305 MT 306 MT 320 MT 330 MT 340 MT 360 MT 361 CR 001341 2+ No Except MT 304 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. 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 001350 2+ No Except MT 304 MT 321 MT 380 MT 381 Add field for place of settlement. To avoid use of free format fields to indicate place of settlement for offshore trades such as CNY that is settled in Hong Kong. This field is optional for outbound messages. MT 304 CR 001301 2- Yes 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. MT 300 MT 304 MT 305 MT 306 MT 340 CR 001298 1 No Except MT 304 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 15 5.7 Category 4 – Collections and Cash Letters There are no changes scheduled for implementation in SR 2018.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 16 5.8 Category 5 – Securities Markets The following changes are scheduled for implementation in SR 2018. 5.8.1 All category 5 messages There are no changes scheduled for implementation in SR 2018. 5.8.2 Trade Initiation and Confirmation MTs 502, 509, 513, 514, 515, 517, 518, 528, 529, 576, 584 (alignment in other messages possible) Message Types (MT) Short description of the modification Impact level MUG MT 513 MT 514 MT 515 MT 518 CR 001321 2- 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. 5.8.3 Settlement and Reconciliation MTs 508, 524, 535-8, 540-9, 578, 586 (alignment in other messages possible) Message Types (MT) Short description of the modification Impact level MUG 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 CR 001295 2- 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. MT 508 MT 536 MT 537 MT 538 CR 001300 2- 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 2015. The deemed income is attributed to the unit holder without being actually distributed.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 17 Message Types (MT) Short description of the modification Impact level MUG 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 level agreement (SLA) exists between the sender and the receiver. MT 508 MT 536 MT 537 MT 538 CR 001317 2- No Add an even type code TXEV, for tax events, add an optional non- repetitive 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 level 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 001321 2- 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. 5.8.4 Corporate Action MTs 564, 565, 566, 567, 568 (alignment in other messages possible) Message Types (MT) Short description of the modification Impact level MUG MT 564 CR 001293 2- 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 15022 and ISO 20022.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 18 Message Types (MT) Short description of the modification Impact level MUG 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 001294 2- 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 001299 2- 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 001300 2- 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 2015. 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 level agreement (SLA) exists between the sender and the receiver.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 19 Message Types (MT) Short description of the modification Impact level MUG MT 564 CR 001304 1 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 001305 2- 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 level agreement (SLA) between the sender and the receiver. MT 564 MT 566 MT 568 CR 001317 2- No Add an even type code TXEV, for tax events, add an optional non- repetitive 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 level agreement (SLA) exists between the sender and the receiver. MT 564 MT 566 CR 001318 2- 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 20 Message Types (MT) Short description of the modification Impact level MUG MT 564 MT 566 CR 001323 1 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. 5.8.5 Collateral Management There are no changes scheduled for implementation in SR 2018. 5.8.6 Other Category 5 changes Message Types (MT) Short description of the modification Impact level MUG MT 575 CR 001295 2- 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 001300 2- 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 2015. 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 level agreement (SLA) exists between the sender and the receiver.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 21 Message Types (MT) Short description of the modification Impact level MUG MT 575 CR 001317 2- Yes Add an even type code TXEV, for tax events, add an optional non- repetitive 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 level agreement (SLA) exists between the sender and the receiver.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 22 5.9 Category 6 – Commodities, Syndications, and Reference Data The following changes are scheduled for implementation in SR 2018. Message Types (MT) Short description of the modification Impact level MUG MT 600 MT 601 CR 001298 1 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 001341 2+ 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 23 5.10 Category 7 – Documentary Credits and Guarantees The following changes are scheduled for implementation in SR 2018. Message Types (MT) Short description of the modification Impact level MUG New MT 744 CR 000838 3 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 000839 3 No Create a new message (MT 759 Ancillary Trade Structured Message). 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 000848 3 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 000833 3 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 24 Message Types (MT) Short description of the modification Impact level MUG MT 707 CR 001110 2+ 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 2018. 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 001111 2+ 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 000830 2+ 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, post- financing 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 000823 2+ 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 000340 2+ 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 25 Message Types (MT) Short description of the modification Impact level MUG MT 730 MT 752 CR 000821 2+ 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 001324 2+ No Add field 50 Changed Applicant Details in new MT 707. This change relates to the new MT 707 that is part of SR 2018. 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 001325 2- 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 CR 000813 2- 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. MT 700 MT 701 MT 705 MT 710 MT 711 MT 720 MT 721 CR 000812 2- 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. MT 700 MT 705 MT 707 MT 710 MT 720 MT 730 MT 732 MT 740 MT 742 CR 000814 2- 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 26 Message Types (MT) Short description of the modification Impact level MUG MT 747 MT 750 MT 752 MT 754 MT 756 MT 700 MT 705 MT 710 MT 720 CR 000824 2- 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 000825 2- 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 000826 2- 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 000828 2- 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 000816 2- 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 27 Message Types (MT) Short description of the modification Impact level MUG MT 734 MT 750 MT 754 CR 000815 2- 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 000831 1 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 000832 1 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 000829 1 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 000827 1 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 000822 1 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 28 Message Types (MT) Short description of the modification Impact level MUG MT 700 CR 001297 1 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.

Standards MT November 2018 Updated High-Level Information Overview of Changes per Category 17 November 2017 29 5.11 Category 8 – Travellers Cheques There are no changes scheduled for implementation in SR 2018.