Updated High-Level Information - Standards MT November 2018 - Swift
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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
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
17 November 2017 2Standards MT November 2018
Updated High-Level Information 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-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
17 November 2017 3Standards MT November 2018
Updated High-Level Information 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 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.
17 November 2017 4Standards MT November 2018
Updated High-Level Information Schedule for SR 2018
2 Schedule for SR 2018
The timeline below describes the schedule for development and implementation of SR
2018.
SR 2018 Timeline
Important This publication provides details of the changes that are approved by the country voting
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 2017 5Standards MT November 2018
Updated High-Level Information Impact Levels of the Change Requests
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.
17 November 2017 6Standards MT November 2018
Updated High-Level Information Evaluation of the Impact on Interfaces and Applications
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.
17 November 2017 7Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
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
Impact
Types Short description of the modification MUG
level
(MT)
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
Impact
Types Short description of the modification MUG
level
(MT)
Header CR 001337 2+ No
Block 3 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. MT 102
These two fields are used in the SWIFT global payment innovation MT 104
(SWIFT gpi) service that allows banks in the SWIFT gpi Closed User MT 105
Group (CUG) to track payments based on a UETR. As of November MT 107
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.
17 November 2017 8Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
Header CR 001338 2+ No
Block 3 Except
Mandate to populate (where not already done so) or pass on, field
121 (Unique End-to-End Transaction Reference (UETR)) in header MT 103
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.
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 CR 001339 2+ No
Block 3
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 CR 001340 2+ No
Block 3
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 CR 001365 1 No
Block 3
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 CR 001366 1 No
Block 3
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 2017 9Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
Header CR 001367 1 No
Block 3
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 CR 001368 1 No
Block 3
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 CR 001404 1 No
codes
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 CR 001405 1 No
codes
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
17 November 2017 10Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
• 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
Impact
Types Short description of the modification MUG
level
(MT)
Cat 1 CR 001337 2+ 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. MT 102
These two fields are used in the SWIFT global payment innovation MT 104
(SWIFT gpi) service that allows banks in the SWIFT gpi Closed User MT 105
Group (CUG) to track payments based on a UETR. As of November MT 107
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 CR 001338 2+ No
MT 103 Except
Mandate to populate (where not already done so) or pass on, field
REMIT 121 (Unique End-to-End Transaction Reference (UETR)) in header MT 103
MT 103 block 3. REMIT
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 a significant impact
on back-office systems.
17 November 2017 11Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 101 CR 001302 1 No
MT 102 Except
Add a usage guideline for use of Chinese commercial codes (CCC)
MT 102 in MT payment messages and refer to the published CCC MT 101
STP conversion table. MT 102
MT 103 To standardise conversion of Chinese characters between CNAPS and MT 103
MT 103 FIN messages, because the FIN character set does not allow for the REMIT
MT 103 use of Chinese characters.
REMIT This change impacts users that have bilaterally agreed to include
MT 103 Chinese characters in MTs.
STP
MT 110
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
Impact
Types Short description of the modification MUG
level
(MT)
Cat 2 CR 001337 2+ 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 111.
17 November 2017 12Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 202 CR 001339 2+ No
COV
Mandate to populate (where not already done so) or pass on, field
MT 205 121 (Unique End-to-End Transaction Reference (UETR)) in header
COV 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 CR 001340 2+ No
MT 205 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 CR 001302 1 No
MT 202 Add a usage guideline for use of Chinese commercial codes (CCC)
COV in MT payment messages and refer to the published CCC
MT 203 conversion table.
MT 205 To standardise conversion of Chinese characters between CNAPS and
MT 205 FIN messages, because the FIN character set does not allow for the
COV use of Chinese characters.
MT 210
This change impacts users that have bilaterally agreed to include
Chinese characters in MTs.
17 November 2017 13Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
5.6 Category 3 – Foreign Exchange, Money Markets,
and Derivatives
The following changes are scheduled for implementation in SR 2018.
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 300 CR 001341 2+ No
MT 304 Except
Add MiFID II client reporting field.
MT 305 MT 304
To support MiFID II Delegated Act article 59 client reporting.
MT 306
It was agreed to add a repetitive optional field to indicate commission
MT 320 and fees.
MT 330
This field is optional for outbound messages.
MT 340
MT 360
MT 361
MT 300 CR 001350 2+ No
MT 304 Except
Add field for place of settlement.
MT 305 MT 304
To avoid use of free format fields to indicate place of settlement for
MT 306 MT 321
offshore trades such as CNY that is settled in Hong Kong.
MT 320 MT 380
MT 321 MT 381
This field is optional for outbound messages.
MT 330
MT 340
MT 341
MT 360
MT 361
MT 380
MT 381
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 CR 001298 1 No
MT 304 Except
Update message usage rules.
MT 305 MT 304
To clarify that a FIN confirmation message cannot create a legal
MT 306 agreement between the parties.
MT 340
This change is a documentation clarification and is expected to have no
technical implementation impact.
17 November 2017 14Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
5.7 Category 4 – Collections and Cash Letters
There are no changes scheduled for implementation in SR 2018.
17 November 2017 15Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
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
Impact
Types Short description of the modification MUG
level
(MT)
MT 513 CR 001321 2- No
MT 514 Add a research fee qualifier to field 19A.
MT 515
To comply with MiFID II, which requires more transparency on research
MT 518 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
Impact
Types Short description of the modification MUG
level
(MT)
MT 536 CR 001295 2- No
MT 537 Add codes SWIF (switch from) and SWIT (switch to) to the qualifier
MT 540 SETR in field 22F.
MT 541 To enable users to indicate the settlement of switch orders.
MT 542
MT 543
This change is optional for outbound messages.
MT 544
MT 545
MT 546
MT 547
MT 548
MT 578
MT 586
MT 508 CR 001300 2- No
MT 536 Add code TAXD for tax debit events, to qualifier CAEV, in field
MT 537 22F. Add also a new optional and non-repetitive deemed payment
MT 538 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.
17 November 2017 16Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
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 CR 001317 2- No
MT 536 Add an even type code TXEV, for tax events, add an optional non-
MT 537 repetitive indicator qualifier TXEV to field 22F and add a network
MT 538 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 CR 001321 2- No
MT 541 Add a research fee qualifier to field 19A.
MT 542
To comply with MiFID II, which requires more transparency on research
MT 543 fees.
MT 544
The group decided to implement qualifier RSCH (aligned with FIX and
MT 545 Omgeo) and not RFEE as initially requested.
MT 546 This change is optional for outbound messages.
MT 547
5.8.4 Corporate Action
MTs 564, 565, 566, 567, 568 (alignment in other messages possible)
Message
Impact
Types Short description of the modification MUG
level
(MT)
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.
17 November 2017 17Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
This change is mandatory and must be implemented in markets where
the Stock Lending Deadline Date/Time element is used.
MT 564 CR 001294 2- No
MT 566 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 CR 001299 2- No
MT 566 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 CR 001300 2- No
MT 566 Add code TAXD for tax debit events, to qualifier CAEV, in field
MT 568 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.
17 November 2017 18Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
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 CR 001305 2- No
MT 567 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 CR 001317 2- No
MT 566 Add an even type code TXEV, for tax events, add an optional non-
MT 568 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 CR 001318 2- No
MT 566 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 2017 19Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 564 CR 001323 1 No
MT 566 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
Impact
Types Short description of the modification MUG
level
(MT)
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.
17 November 2017 20Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
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.
17 November 2017 21Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
5.9 Category 6 – Commodities, Syndications, and
Reference Data
The following changes are scheduled for implementation in SR 2018.
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 600 CR 001298 1 No
MT 601 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 CR 001341 2+ No
MT 601 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 2017 22Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
5.10 Category 7 – Documentary Credits and
Guarantees
The following changes are scheduled for implementation in SR 2018.
Message
Impact
Types Short description of the modification MUG
level
(MT)
New CR 000838 3 No
MT 744 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 CR 000839 3 No
MT 759 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 CR 000833 3 No
MT 708 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 2017 23Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
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 CR 000830 2+ No
MT 701 Add two new fields: Special Payment Instructions for
MT 710 Beneficiary/Receiving Bank.
MT 711 These two fields will provide a place for information that is now put in
MT 720 other free format fields. The first field specifies special payment
MT 721 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 CR 000823 2+ No
MT 710 Add new field for Requested Confirmation Party after field 49
MT 720 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.
17 November 2017 24Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 730 CR 000821 2+ No
MT 752 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 CR 001325 2- No
MT 705 Remove field 39B Maximum Credit Amount, which contains only
MT 710 one code NOT EXCEEDING.
MT 720 This change relates to the updated MT 700 and related messages.
MT 740 This code does not seem to make any difference, being present or not.
MT 747
This is a mandatory change with no expected business impact.
MT 700 CR 000813 2- No
MT 710 Use z character set in all charges fields and change the field letter
MT 720 option where necessary.
MT 730 The X character set lacks some commonly used characters for example
MT 740 %, @, &. Current workarounds are not satisfactory.
MT 742
MT 750 This change is optional for senders. Receivers must be able to accept
MT 752 and process messages that contain the z character set.
MT 754
MT 700 CR 000812 2- No
MT 701 Use z character set in field 45A, 46A and 47A.
MT 705
The X character set lacks some commonly used characters for example
MT 710 %, @, &. Current workarounds are not satisfactory.
MT 711
MT 720
This change is optional for senders. Receivers must be able to accept
MT 721 and process messages that contain the z character set.
MT 700 CR 000814 2- No
MT 705 Change field 72 to 72Z to allow the use of the z character set.
MT 707
The x character set lacks some commonly used characters for example
MT 710 %, @, &. Current workarounds are not satisfactory.
MT 720
MT 730
This change is optional for senders. Receivers must be able to accept
MT 732 and process messages that contain the z character set.
MT 740
MT 742
17 November 2017 25Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 747
MT 750
MT 752
MT 754
MT 756
MT 700 CR 000824 2- No
MT 705 Delete all codes that relate to revocable documentary credits from
MT 710 field 40A.
MT 720 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 CR 000825 2- No
MT 710 Change the format of field 43P and introduce codes.
MT 720
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 CR 000826 2- No
MT 710 Change the format of field 43T and introduce codes.
MT 720
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 CR 000828 2- No
MT 710 Change format and definition of field 48.
MT 720
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 CR 000816 2- No
MT 750 Use z character set in fields 77J and 77A.
MT 754
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 2017 26Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 734 CR 000815 2- No
MT 750 Change field 73 to 73A to allow the use of the z character set.
MT 754
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 CR 000831 1 No
MT 701 Change usage rule in fields 45a, 46a, and 47a.
MT 710
The rule about the number of occurrences of these fields is too
MT 711 restrictive and many institutions are forced to bypass it, as this is not a
MT 720 network-validated rule. This change aligns the usage rule with the
MT 721 market practice.
This changes is mandatory, but is expected to have minimal business
impact.
MT 700 CR 000832 1 No
MT 701 Change usage rule about number of continuation messages.
MT 710
The limit of three continuation messages is too low and many
MT 711 institutions send more than three, as this is not a network-validated
MT 720 rule. This change aligns the usage rule with the market practice.
MT 721
This changes is mandatory, but is expected to have minimal business
impact.
MT 700 CR 000829 1 No
MT 710 Change definition in field 49.
MT 720
To clarify the definition.
This is a documentation change that does not impact the message
structure.
MT 700 CR 000827 1 No
MT 710 Rename field 48 Period for Presentation to "Period for
MT 720 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 CR 000822 1 No
MT 710 Rename field 42P Deferred Payment Details to
MT 720 "Negotiation/Deferred Payment Details".
MT 740 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 2017 27Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
Message
Impact
Types Short description of the modification MUG
level
(MT)
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.
17 November 2017 28Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
5.11 Category 8 – Travellers Cheques
There are no changes scheduled for implementation in SR 2018.
17 November 2017 29Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
5.12 Category 9 – Cash Management and Customer
Status
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:
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 2020.
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 910 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.
17 November 2017 30Standards MT November 2018
Updated High-Level Information Overview of Changes per Category
5.13 Category n – Common Group Messages
The following changes are scheduled for implementation in SR 2018.
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT n98 CR 001322 2- 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 001335 2- 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 001336 2- 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 2017 31Standards MT November 2018
Updated High-Level Information 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 2019.
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 760 CR 000847 3 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 000849 3 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 000850 3 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 000997 2+ 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 CR 001309 2+ Yes
MT 304 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 2017 32Standards MT November 2018
Updated High-Level Information Change Requests Postponed to a Later Standards Release
Message
Impact
Types Short description of the modification MUG
level
(MT)
MT 300 CR 001310 2+ Yes
MT 304 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 001332 2+ No
Add an optional field for Transfer Conditions.
This change relates to the new MT 760 that is part of SR 2019.
Change is optional for the sender.
MT 768 CR 000852 2+ No
MT 769 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 CR 000814 2- No
MT 769 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 CR 000813 2- No
MT 769 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 CR 000820 2- No
MT 769 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 2017 33You can also read
