Swift Standards Infopaper

7/25/2019 Swift Standards Infopaper

1/42

Standards

Standards MT November 2015

Updated High-Level Information

This document is an updated version of the High-Level Information document that was published on www.swift.comon 29 August 2014. All the expected or requested changes described in that document were validated by amaintenance working group and were either approved or rejected. Country user groups voted on the approvedrequests 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 areforeseen for implementation at the same time as the Standards MT Release. The purpose of this document is to helptechnical implementers and operational users of the Standards MT messages to evaluate the impact of changes oninterfaces and applications.

21 November 2014
http://www.swift.com/http://www.swift.com/http://www.swift.com/http://www.swift.com/


2/42


2 Updated High-Level Information

Table of ContentsTable of Contents ...............................................................................................................................2

Preface .................................................................................................................................................3

1 Introduction ...............................................................................................................................4

2 Schedule for SR 2015 ...............................................................................................................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 Impact on Category 0 FIN System Messages ........................................................................ 8

5.2 Other Technical Changes ....................................................................................................... 9

5.3 Impact on Category 1 Customer Payments and Cheques ...................................................10

5.4 Impact on Category 2 Financial Institution Transfers ...........................................................12

5.5 Impact on Category 3 Treasury Markets ...............................................................................14

5.6

Impact on Category 4 Collections and Cash Letters ............................................................175.7 Impact on Category 5 Securities Markets .............................................................................18

5.7.1 Trade Initiation and Confirmation ..................................................................................... 18

5.7.2 Settlement and Reconciliation .......................................................................................... 18

5.7.3 Corporate Action ............................................................................................................... 19

5.7.4 Collateral Management .................................................................................................... 19

5.7.5 Other Category 5 Changes ............................................................................................... 20

5.8 Impact on Category 6 Treasury Markets-Commodities and Syndications ............................21

5.9 Impact on Category 7 Documentary Credits and Guarantees ..............................................22

5.10 Impact on Category 8 Travellers Cheques ...........................................................................23

5.11 Impact on Category 9 Cash Management and Customer Status .........................................24

5.12 Impact on Category n Common Group Messages ...............................................................26

6

Change Requests Postponed to a Later Standards Release ............................................27

7 Rejected and Withdrawn Change Requests ........................................................................36

Legal Notices ....................................................................................................................................42


3/42

Preface

21 November 2014 3

PrefacePurpose of this document

This document gives an overview of all MT change requests received by SWIFT Standards forthe next Standards MT Release. The purpose of this document is to provide the SWIFTcommunity with an update to the initial high-level information that was published in August 2014.

Technical implementers and operational users of the MT messages can use this document toevaluate the impact on interfaces and applications.

This document is not intended to be final. After the MWG review of the change requests, usergroup chairpersons of all countries were invited to discuss the change requests in their usergroup and to vote on the acceptance or rejection of individual change requests. The SWIFTBoard 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


4/42



1 Introduction

Warning This document describes changes that have been validated by a maintenanceworking group and approved by Board business committees. The changes have beenaccepted by country user group votes and the Board will ratify the voting results at itsDecember 2014 meeting.

The Updated High-Level Information document is part of the normal standards development andimplementation procedures. This document describes the expected or requested changes forStandards MT Release 2015 (SR 2015). SWIFT distributes this document 12 months before thestandards release live date.

This document also includes other technical changes that are foreseen for implementation at thesame time as the Standards Release, for example, changes to system messages.

The sole purpose of this document is to help technical implementers and operational users of theSWIFT messages to evaluate the impact of changes on interfaces and applications.Consequently, implementers and users can plan resources and budget allocations for the SR2015 implementation.

As a guide for implementers, a note has been added to each change request to indicate whethera change is mandatory or optional. Each institution must assess their own applications andbusiness needs when implementing these changes.

The Standards MT Release Guide 2015, which SWIFT will publish in December 2014, will fullydescribe the SR 2015. Approved changes will be effective as of 22 November 2015, the releasedate on FIN.

Note This publication is supplied for information purposes only, and shall not be bindingnor shall it be construed as constituting any obligation, representation or warranty onthe part of SWIFT. The information in this publication is the latest available at the dateof its production, and may change.


5/42

Schedule for SR 2015

21 November 2014 5

2 Schedule for SR 2015This timeline describes the schedule for development and implementation of SR 2015.

SR 2015 Timeline

Note This publication provides details of the changes that are approved by the countryvoting process. While this provides a good overview of all the expected changes forthe next release, the only official source for information about a standards release isthe Standards Release Guide that is published in December.


6/42



3 Impact Levels of the Change RequestsAll change requests contain an evaluation of their impact on interfaces and applicationsexpressed as a number in the range [0 - 3] with or without a plus (+) or minus (-) sign as in thefollowing table.

Index of impact levels

Level 0 This is a minor change that does not impact the format of the message. Forexample, the scope of the message is updated, which may have an impact on someautomated applications.

Level 1 This change relates to the use of the message format but does not affect themessage structure or the FIN validation, for example, a definition or a usage rule ischanged.

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, forexample, field formats, qualifiers or codes are added or deleted.

Level 2+ The message layout or the FIN validation or both are significantly impacted, forexample, 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 useof 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 receiveand process the new message.


7/42

Evaluation of the Impact on Interfaces and Applications

21 November 2014 7

4 Evaluation of the Impact on Interfaces andApplications

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 may bedifferent for applications sending the message than for applications receiving the message.

Some changes apply to message types (to be) implemented in a Message User Group (MUG). Incase of non-registration to the MUG, users can not send or receive message of this type. Theimpact on any application depends directly on the need or desire to support these messagetypes.


8/42



5 Overview of Changes per CategoryWhen a change description is not clear without further explanation, a brief business context issometimes 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 bluefont.As a guide for implementers, a note has been added, in red, to each change request to indicatewhether 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 Impact on Category 0 FIN System MessagesThe following changes are scheduled for implementation in SR 2015.

MessageTypes(MT)

Short description of the modificationImpactlevel

MUG

MT 066

MT 082

MT 083

CR 000917 2- NA

Add a report generat ion date and t ime field .

To indicate the date and time, local to the receiver, at which the reportis generated.

MT 074

MT 094

CR 000921 2- NA

Add a code to the MT 074 and MT 094.

To allow for the distribution of Securities SSIs.


9/42

Overview of Changes per Category

21 November 2014 9

5.2 Other Technical ChangesThere are no changes for implementation in SR 2015.


10/42



5.3 Impact on Category 1 Customer Payments andChequesThe following changes are scheduled for implementation in SR 2015.

MessageTypes

(MT)


MUG

MT 101

MT 102

MT 102STP

MT 103

MT 103REMIT

MT 103STP

CR 000760 2+ YesExcept

MT 102STP

MT 103

MT 103STP

Add a network validated rule to prevent the use of commodit iescodes XAU (gold), XAG (silver), XPD (palladium) and XPT(platinum) in currency fields and subfields.

To stop the misuse of Payments messages to settle commodities whenspecific category 6 messages are available for this purpose, forexample, the MT 604 Commodity Transfer/Delivery Order.

This change will only impact users that today misuse the Paymentsmessages for the settlement of commodities.

MT 101MT 102

MT 102STP

MT 103

MT 103REMIT

MT 103STP

CR 000653 2+ YesExcept

MT 102STP

MT 103

MT 103STP

PART 1: Add letter option F to f ield 59a, Beneficiary Customer, inPayments messages.

PART 2: In a later release, remove the free format options fromfield 50a Ordering Customer and field 59a Beneficiary Customer.

To provide a structured implementation of name and addressinformation and to facilitate filtering, for example on country code, forregulatory reporting.

Part 1 will be implemented in SR 2015.

Part 2 will be implemented in a later release. The release date will bedecided after the community has had time to do a full impact analysis.

All users must be able to receive and process Payments messageswith this new letter option in field 59. The impact will be high.

MT 101

MT 102

MT 102STP

MT 103

MT 103REMIT

MT 103STP

CR 000758 2- YesExcept

MT 103

MT 103STP

MT 102STP

Align the ex is ting documentat ion for field 50F Order ing Cus tomerwith the published advanced information for field 59F BeneficiaryCustomer, regarding information that covers similar businessfunctionality.

To increase consistency within the Payments messages.

Only senders who wish to use the new features will be impacted but allusers must be able to receive and to process messages that contain

these changes.


11/42


21 November 2014 11

MessageTypes(MT)


MUG

MT 102STP

MT 103STP

CR 000751 2- No

Add count ry code HR (Croat ia) to the network val idated rule thatvalidates the IBAN format and syntax validation in field 59aBeneficiary Customer, subfield Account.

To improve STP for messages exchanged between European andCroatian banks. IBAN is the only allowed account identification inCroatian Banks since 1st of June 2014.

This change only impacts messages exchanged between the countrieslisted in the network validated rule.

Cat 1 CR 000759 1 NA

Delay until SR 2018, at the earliest, the implementation of PART 2of CR 000653, which is to remove the free format options fromfield 50a Ordering Customer and field 59a Beneficiary Customer.

To allow banks time to analyse the full impact on back offices and on

the business and to follow up on the finalisation of regulation regardingformatting of ordering customer and beneficiary customer in paymentsmessages.

This request has no impact on users for SR 2015. It is linked to CR000653 and the change will be implemented in a later release, the dateof which is still to be determined.

MT 101

MT 102

MT 102STP

MT 103

MT 103REMIT

MT 103STP

MT 104

MT 107

MT 110

MT 111

MT 112

CR 000750 1 NoExcept

MT 101

MT 102

MT 103

REMITMT 104

MT 107

Add the Chinese CNAPS clear ing code in existing l is ts of clearingcodes.

To improve STP for the increasing number of RMB payments and tomake sure that the MT messages can be easily mapped to CNAPS

messages.

This change will facilitate automation of Payments to China but it is notmandatory for senders to use this new code. All banks in China mustbe able to receive and process messages received with this newclearing code.

MT 103

MT 103REMIT

CR 000752 1 YesExcept

MT 103Add a usage rule and clar if y the use of the code word INS, when

there were multiple previous instructing institutions involved inearlier phases of the payment chain.

To ensure transparency and, in the event of a regulatory enquiry, tohelp meet requirements to indicate the complete end to end paymentchain.

This change is optional but all users must be able to receive and toprocess messages with multiple occurrences of code INS in field 72.


12/42



5.4 Impact on Category 2 Financial Insti tut ionTransfersThe following changes are scheduled for implementation in SR 2015.

MessageTypes

(MT)


MUG

MT 200

MT 201

MT 202

MT 202COV

MT 203

MT 205

MT 205COV

MT 207

MT 210

CR 000760 2+ NoExcept

MT 207Add a network validated rule to prevent the use of commodit iescodes XAU (gold), XAG (silver), XPD (palladium) and XPT(platinum) in currency fields and subfields.

To stop the misuse of Payments messages to settle commodities whenspecific category 6 messages are available for this purpose, forexample, the MT 604 Commodity Transfer/Delivery Order.

This change will only impact users that today misuse the Paymentsmessages for the settlement of commodities.

MT 202COV

MT 205COV

CR 000653 2+ No

PART 1: Add letter option F to f ield 59a, Beneficiary Customer, inPayments messages.

PART 2: In a later release, remove the free format options fromfield 50a Ordering Customer and field 59a Beneficiary Customer.

To provide a structured implementation of name and addressinformation and to facilitate filtering, for example on country code, forregulatory reporting.

Part 1 will be implemented in SR 2015.

Part 2 will be implemented in a later release. The release date will be

decided after the community has had time to do a full impact analysis.

All users must be able to receive and process Payments messageswith this new letter option in field 59. The impact will be high.

MT 202COV

MT 205COV

MT 210

CR 000758 2- No

Align the ex is ting documentat ion for field 50F Order ing Cus tomerwith the published advanced information for field 59F BeneficiaryCustomer, regarding information that covers similar businessfunctionality.


Only senders who wish to use the new features will be impacted but all

users must be able to receive and to process messages that containthese changes.


13/42


21 November 2014 13

MessageTypes(MT)


MUG

Cat 2 CR 000759 1 NA


To allow banks time to analyse the full impact on back offices and onthe business and to follow up on the finalisation of regulation regardingformatting of ordering customer and beneficiary customer in paymentsmessages.


MT 200

MT 201

MT 202

MT 202COV

MT 203

MT 204

MT 205

MT 205COV

MT 207

MT 210

MT 256


MT 204

MT 207

MT 256


To improve STP for the increasing number of RMB payments and tomake sure that the MT messages can be easily mapped to CNAPSmessages.


MT 202

MT 202

COVMT 203

MT 205

MT 205COV

CR 000752 1 No

Add a usage rule and clar if y the use of the code word INS, when

there were multiple previous instructing institutions involved inearlier phases of the payment chain.

To ensure transparency and, in the event of a regulatory enquiry, tohelp meet requirements to indicate the complete end to end paymentchain.

This change is optional but all users must be able to receive and toprocess messages with multiple occurrences of code INS in field 72.


14/42



5.5 Impact on Category 3 Treasury MarketsThe following changes are scheduled for implementation in SR 2015.

MessageTypes(MT)


MUG

MT 304 CR 000801 2+ Yes

Add new f ields for t rade repository reporting.

To be able to report to the trading repositories.

This change is optional and is only needed when the message is usedfor reporting to a trade repository.

MT 305 CR 000799 2+ No

Add f ields for deliverable vs net cash and for the f loating rate.

To be able to confirm deliverable and cash settled options.

This change is optional for including a settlement rate source for vanillaoptions.

MT 306 CR 000798 2+ No

Make optional subsequence F1 Barrier Window Block repetitive.

To allow multiple window barrier transactions to be confirmed.

This change is optional and only required when confirming multiplewindows in barrier transactions.

MT 306 CR 000797 2+ No

Make optional sequence G Trigger Block repetitive.

To allow multiple currency barrier and binary transactions to beconfirmed.

This change is optional and only required when confirming multipletrigger transactions.

MT 306 CR 000796 2+ No

Add a new opt ional sequence for optional ear ly terminations.

To be able to confirm early terminations.

This change is optional and only required when confirming earlyterminations.

MT 306 CR 000794 2+ No

Add a new sequence for barrier and binary products.

To be able to confirm exotic barrier and binary products.

This change is optional and only required for provision of time andlocation in the settlement rate source.


15/42


21 November 2014 15

MessageTypes(MT)


MUG

MT 306 CR 000793 2+ No

Expand detail and repetitiveness of field 14S Settlement RateSource.

To allow time and location to be stipulated as well as allowing multiplesettlement rates sources.

It is mandatory for all users to be able to receive and processmessages with this updated field.

MT 306 CR 000792 2+ No

Add new opt ional fields for averaging option transact ions.

To be able to confirm averaging option products.

This change is optional and only required when confirming average rateoption transactions.

MT 306 CR 000791 2+ No

Add new opt ional fields for averaging forward transact ions.

To be able to confirm averaging forward products.

This change is optional and only required when confirming average rateforward transactions.

MT 361

MT 362

MT 365

CR 000800 2+ No

Add a new opt ional sequence for volat il ity, var iance andcorrelation swaps transactions.

To be able to confirm and terminate volatility, variance and correlation

swaps transactions.

This change is optional and only required when confirming volatility,variance and correlation swaps transactions.

MT 370 CR 000786 2+ NA

Add two new optional party identi fication f ields in the MT 370Netting Position Advice.

To enable wider usage of the message.

This change is optional for further identification of the parties.

MT 306 CR 000795 2- NoAdd codes to the f ield 22G Type of Barrier.

To be able to confirm knock in knock out and knock out knock inoptions.

This change is mandatory when confirming knock-in knock-out andknock-out knock-in barrier options.


16/42



MessageTypes(MT)


MUG

MT 300

MT 305

MT 306

MT 340

MT 341

MT 360

MT 361

CR 000790 1 No

Add codes for addit ional reporting jurisdic tions.

To improve regulatory reporting.


MT 360

MT 361

CR 000789 1 No

Add a new usage rule for describ ing a f loating rate.

To align with other usage rules for floating rates.

This is a mandatory usage rule when describing a floating rate forswaps.

MT 370 CR 000750 1 NA





17/42


21 November 2014 17

5.6 Impact on Category 4 Collections and CashLettersThere are no changes for implementation in SR 2015.


18/42



5.7 Impact on Category 5 Securities MarketsThe following changes are scheduled for implementation in SR 2015.

5.7.1 Trade Init iation and Confi rmation

MTs 502, 509, 513, 514, 515, 517, 576, (alignment in other messages possible)

MessageTypes(MT)


MUG

MT 502

MT 513

MT 514

MT 515

MT 518

CR 000914 1 No

Correct defini tions of qualif iers DEI1, DEI2, REI1 and REI2.

To align the definitions with the description of the network validatedrules.

Definition change with very low impact on users business applications.

5.7.2 Sett lement and Reconcil iation

MTs 508, 524, 535-8, 540-9, 578, 586, (alignment in other messages possible)

MessageTypes(MT)


MUG

MT 535 CR 000739 2+ No

To change the definition of the qualifier in field 93a::PLED andaddition of a new field 22F and new qualifiers in field 94a.

To comply with regulatory reporting requirements.

This change is optional as use of the field is linked to market practice or

to a service level agreement (SLA) between the sender and receiver.High impact known on US users.

MT 536

MT 537

MT 540

MT 542

MT 544

MT 546

CR 000741 2- No

Add a re-hypothecat ion code (RHYP) in f ield 22F::STCOSettlement Transaction Condition Indicator

To improve STP for re-hypothecation agreements.

This change is optional as use of the field is linked to market practice orto a service level agreement (SLA) between the sender and receiver.High impact known on US users.


19/42


21 November 2014 19

MessageTypes(MT)


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 000914 1 No




MT 548

MT 549

CR 000748 1 No

Change the definit ion of status code in ISO 15022 messages toalign them with definitions in ISO 20022 messages.

To enable the use of TPRC qualifier "Processing Change CommandStatus" to provide a status of other messages than the MT 530.


MT 548

MT 549

CR 000743 1 No

Change the definit ions o f the denied reason codes in ISO 15022and ISO 20022 messages.

To make the definitions more generic.


5.7.3 Corporate Action

MTs 564, 565, 566, 567, 568, (alignment in other messages possible)

Al l Corporate Act ion changes are postponed to a later release.

5.7.4 Collateral Management

MTs 503-507, 527, 558, 569, (alignment in other messages possible)

MessageTypes

(MT)


MUG

MT 504

MT 505

MT 507

CR 000914 1 Yes





20/42



Al l o ther Collateral Management changes are postponed to a later release.

5.7.5 Other Category 5 Changes

MessageTypes(MT)


MUG

MT 559 CR 000750 1 No




MT 575 CR 000914 1 Yes





21/42


21 November 2014 21

5.8 Impact on Category 6 Treasury Markets-Commodities, Syndications, and Reference DataThe following changes are scheduled for implementation in SR 2015.

MessageTypes

(MT)


MUG

MT 600

MT 601

MT 604

MT 605

MT 606

MT 607

MT 608

MT 609

MT 620


MT 620Introduce a network validated rule to enforce the use of unit codeGOZ for "white" metals (silver, palladium and platinum).

To prevent mismatching of white metal trades.

This change is mandatory and will impact those who trade whitemetals.

MT 600

MT 601

CR 000790 1 No

Add codes for addit ional reporting jurisdic tions.

To improve regulatory reporting.


MT 670

MT 671

CR 000750 1 No





22/42



5.9 Impact on Category 7 Documentary Credits andGuaranteesThe following changes are scheduled for implementation in SR 2015.

MessageTypes

(MT)


MUG

MT 734 CR 000851 0 No

Change definition of the code word "HOLD" in field 77B Disposalof Documents

To align with the change in the rules for the business that followed thechange from ICC UCP 500 to ICC UCP 600 in 2007.

This change should have no impact on users, as the new definition ofthe code is already implemented by all users of the message.


23/42


21 November 2014 23

5.10 Impact on Category 8 Travellers ChequesThere are no changes for implementation in SR 2015.


24/42



5.11 Impact on Category 9 Cash Management andCustomer StatusThe following changes are scheduled for implementation in SR 2015.

MessageTypes

(MT)


MUG

MT 900

MT 910

CR 000761 2+ No

Add a f ield 13D Date/Time Indication to the MT 900 Conf irmation ofDebit and MT 910 Confi rmation of Credit .

To facilitate intraday liquidity monitoring requirements by using the fieldas a timestamp for the transaction.

This is an optional field. Account owners that wish to have betterliquidity risk-management will ask their account servicing institutions toprovide date and time details to the confirmation messages. Theseaccount servicers will need to implement this change.

MT 910 CR 000758 2- NoAlign the ex is ting documentat ion for field 50F Order ing Cus tomerwith the published advanced information for field 59F BeneficiaryCustomer, regarding information that covers similar businessfunctionality.


Only senders who wish to use the new features will be impacted but allusers must be able to receive and to process messages that containthese changes.

Cat 9 CR 000759 1 NA


To allow banks time to analyse the full impact on back offices and onthe business and to follow up on the finalisation of regulation regardingformatting of ordering customer and beneficiary customer in paymentsmessages.



25/42


21 November 2014 25

MessageTypes(MT)


MUG

MT 900

MT 910

CR 000750 1 No





26/42



5.12 Impact on Category n Common Group MessagesThere are no changes for implementation in SR 2015.


27/42

Change Requests Postponed to a Later Standards Release

21 November 2014 27

6 Change Requests Postponed to a LaterStandards ReleaseThe changes in this section are held over for a future release. The release will be decided at alater date.

MessageTypes(MT)


MUG

MT 502

MT 509

MT 515

CR 000912 2+ No

Delete codes SUBS, REDM, CROF, CROT, SWIF, SWIT and DIVRfrom f ield 22H, qualifier BUSE.

This is to support the community decision to migrate to a singlestandard for Funds order processing by the removal the tactical ISO15022 solutions for funds. This change is the completion of an 8 yearcommunity driven migration programme validated and confirmed by theindustry in 2011.

MT 564

MT 565

MT 566

MT 568

CR 000772 2- No

Add opt ional , repeti tive qual if ier CETI Certi fication/Breakdownnarrative in field 70E Narrative in sequence F AdditionalInformation in MT 564 Corporate Action Notification.

Add opt ional , repeti tive qual if ier CETI Certi fication / Breakdownnarrative and qualifi er TXNR Narrative Version in field 70aNarrative in sequence C Additional Information in MT 568Corporate Action Narrative.

To harmonise the presence of the "certification/breakdown" and"narrative version" narrative qualifiers between the corporate action

notification and the narrative messages.

This change is optional as use of the field is linked to market practice orto a service level agreement (SLA) between the sender and receiver.Medium impact on users business applications.

MT 564

MT 566

CR 000780 2- No

Add two indicator codes NREF Non-Refunded Secur it y and REFURefunded Security to qualifi er NSIS New Securi ties IssuanceIndicator in field 22F Indicator, in sequence E1 SecuritiesMovement of MT 564 Corporate Action Notification and insequence D1 Securit ies movement of MT 566 Corporate ActionConfirmation.

To be able to differentiate between the refunded and non-refundedsecurities for partial pre-refunding (PDEF) events.

This change is optional as use of the field is linked to market practice orto a service level agreement (SLA) between the sender and receiver.Low impact on users business applications.


28/42



MessageTypes(MT)


MUG

MT 564

MT 566

CR 000779 2- No

Add codes FPRE Ful l Pre-Refunding and PPRE Part ial Pre-Refunding to qualifier CAEV Corporate Action Event Indicator infield 22F Indicator, in sequence A General Information of all MT

56X Corporate Act ion messages.

Amend the defini tion of indicator code PDEF in quali fier CAEVCorporate Action Event Indicator in field 22F Indicator, insequence A General Information of all MT56X Corporate Actionmessages.

To be able to distinguish between the three different partialdefeasance/pre-funding scenarios in the US market. Currently there isa single event type covering those three scenarios in the messages.

The MWG agreed to create two new codes, FPRE and PPRE, inAdditional Business Process Indicator :22F::ADDB, in sequence D ofMT 564 and in sequence C of MT 566.


MT 564

MT 566

CR 000920 2- No

(Previously CR 000777) Add the new codes MPUT Mandator y PutRedemption and PPUT Partial Mandatory Put Redemption toqualifier CAEV Corporate Action Event Indicator in field 22FIndicator, in sequence A General Information of all MT 56XCorporate Action messages.

To be able to distinguish the three put redemption scenarios that existin the US, while only one put redemption event BPUT is present in themessages.

The MWG agreed to create one new code, PPUT, in AdditionalBusiness Process Indicator :22F::ADDB in sequence D of MT 564 andin sequence C of MT 566.


MT 564 CR 000775 2- No

Add opt ional , non-repet it ive quali fier BPRD Buyer Protect ionResponse Deadline in field 98a Date/Time, in sequence DCorporate Action Details of MT 564 Corporate Action Notification.

To enable the account servicers/CSDs to provide a client responsedeadline prior to the buyer protection deadline.

The MWG agreed to add an optional, non-repeatable qualifier ECRDElection To Counterparty Response Deadline to field :98a::Date/Time insequence D of MT 564 and to rename the existing element Election toCounterparty Deadline to Election to Counterparty Market Deadline.



29/42


21 November 2014 29

MessageTypes(MT)


MUG

MT 564 CR 000778 2- No

Make qualif ier DIVI Dividend Type Indicato r repeatable in field 22FIndicator, in sequence D Corporate Action Details of MT 564Corporate Action Notification.

To make it possible to mention more than one non-mutually-exclusivetype of dividend.

The MWG agreed to add a new code, SPRE, in field :22F::DIVIDividend Type Indicator, in sequence D of MT 564.


MT 564 CR 000771 2- No

Add code REAC Required Act ion to qual if ier ADDB Addit ionalBusiness Process Indicator, in field 22F Indicator, in sequence DCorporate Action Details of MT 564 Corporate Action Notification.

Add opt ional , non-repet it ive quali fier APLI Appl ied Option Flag tofield 17B Flag, in sequence E Corporate Action Options , in MT 564Corporate Action Notification.

To enable an account owner to distinguish between commonmandatory events (MAND) and mandatory events that require an actionon its side, in order to receive the entitlement/proceeds.


MT 564 CR 000776 2- No

Add subsequence E3 Borrower Stock Lending Deadl ine in MT 564

Corporate Action Notification with new, mandatory, non-repeatable qualifier BORD Stock Lending Deadline in field 98aDate/Time and with new, mandatory, non-repeatable qualifierBORW Borrower in f ield 95a.

Delete optional qualifi er BORD Stock Lending Deadline Date/Timein field 98a Date/Time, in sequence E Corporate Action Option ofMT 564 Corporate Action Notification.

To enable the custodians to provide one stock lending deadline perborrower, when there is more than one borrower.

The MWG agreed to make the qualifier BORD Stock Lending DeadlineDate/Time repeatable in field :98a: Date/Time, in sequence E of MT564 and to create two new format options, G and H, in the same field inorder to associate a date and time with a party either as a BIC or as a

proprietary identificationThis change is optional as use of the field is linked to market practice orto a service level agreement (SLA) between the sender and receiver.Medium impact on users business applications.


30/42



MessageTypes(MT)


MUG

MT 566 CR 000770 2- No

Add format option M to quali fiers SOFE Soli citat ion Fee Rate andESOF Early Solici tation Fee Rate in field 92a Rate, in sequence D2Cash Movement of MT 566 Corporate Action Confirmation.

To have consistent format options for solicitation fee and earlysolicitation fee rates between the corporate action notification and thecorporate action confirmation messages.


MT 700

MT 701

MT 705

MT 710

MT 711MT 720

MT 721

CR 000812 2- No

Use z character set in fi eld 45A Descrip tion of Goods and /orServices

The X character set lacks some commonly used characters for example

%, @, &. Current workarounds are not satisfactory.

MT 700

MT 701

MT 710

MT 711

MT 720

MT 721

CR 000830 2+ No

Add two new fields: Special Payment Instruct ions forBeneficiary/Receiving Bank

These two fields will provide a place for information that is now put inother free format fields. The first field specifies special paymentconditions applicable to the beneficiary, for example, post-financingrequest/conditions for Beneficiary. The second field specifies specialpayment conditions applicable to the receiving bank, for example, post-financing request/conditions for Receiving bank only.

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 3 continuation messages is too low and many institutionssend more than 3, as this is not a network-validated rule. This changealigns the usage rule with the market practice.

MT 700

MT 701

MT 710

MT 711

MT 720

MT 721

CR 000831 1 No

Change usage rule in fields 45a Description of Goods and/orServices, 46a Documents Required, 47a Additional Conditions

The rule about the number of occurrences of these fields is toorestrictive and many institutions are forced to bypass it, as this is not anetwork-validated rule. This change aligns the usage rule with themarket practice.


31/42


21 November 2014 31

MessageTypes(MT)


MUG

MT 700

MT 705

MT 707

MT 710

MT 720

MT 730

MT 732

MT 740

MT 742

MT 747

MT 750

MT 752

MT 754

MT 756

MT 768

MT 769

CR 000814 2- No

Use z character set in field 72 Sender to Receiver Information

The X character set lacks some commonly used characters for example%, @, &. Current workarounds are not satisfactory.

MT 700

MT 705

MT 707

MT 710

MT 720

MT 740

CR 000818 2- No

Change format in field 59 Beneficiary

Name and address fields are too short and need to be increased to 6lines. Prefixes are also needed to identify name, address and countrylines. Automatic extraction of country code is needed for compliancereasons.

MT 700

MT 705

MT 710

MT 720

CR 000817 2- No

Change format of field 50 ApplicantName and address fields are too short and need to be increased to 6lines. Prefixes are also needed to identify name, address and countrylines. Automatic extraction of country code is needed for compliancereasons.

MT 700

MT 705

MT 710

MT 720

CR 000824 2- No

Delete all codes that relate to revocable documentary credits fromfield 40A.

In practice, revocable instruments no longer exist. These codes are

therefore obsolete and must be removed.


32/42



MessageTypes(MT)


MUG

MT 700

MT 705

MT 710

MT 720

MT 730

MT 734

MT 740

MT 742

MT 750

MT 752

MT 754

MT 756

MT 768

MT 769

CR 000820 2- No

Change format of party fields which identify banks.


MT 700

MT 705

MT 710

MT 720

MT 740

CR 000819 2- No

Change format of field 41D Available With By


MT 700

MT 707

MT 710

MT 752

MT 760

MT 767

CR 000650 2- No

Add network validat ion for codes in field 23 of MT 700, 707, 710,752, 760 and 767.

To improve STP by checking that the appropriate codes are used.

MT 700

MT 710

MT 720

CR 000823 2+ No

Add new f ield for Requested Conf irmat ion Party af ter field 49Confirmation Instructions

In some scenarios, it is not always clear which bank is requested to addits confirmation, this field is therefore required to specify it.

MT 700MT 710

MT 720

CR 000825 2- NoChange the format of field 43P Partial Shipment and introducecodes.

To make the field more precise and more structured, to allow forautomation.


33/42


21 November 2014 33

MessageTypes(MT)


MUG

MT 700

MT 710

MT 720

CR 000826 2- No

Change the format of field 43T Transshipment and introducecodes.

To make the field more precise and more structured, and to allow forautomation.

MT 700

MT 710

MT 720

CR 000828 2- No

Change format and definit ion of field 48 Period for Presentation

To make the field more precise and more structured, and to allow forautomation.

MT 700

MT 710

MT 720

CR 000827 1 No

Rename field 48 Period for Presentation to "Period forPresentation in days"

Clarify field name in line with the format change.

MT 700

MT 710

MT 720

CR 000829 1 No

Change definition in field 49 Confirmation Instructions

Clarify the definition.

MT 700

MT 710

MT 720

MT 730

MT 740

MT 742

MT 750

MT 752

MT 754

MT 768

MT 769

CR 000813 2- No

Use z character set in all charges fields.


MT 700

MT 710

MT 720

MT 740

CR 000822 1 No

Rename field 42P Deferred Payment Details to"Negotiation/Deferred Payment Details"

Clarify the field name as the field can also be used for negotiationdetails.


34/42



MessageTypes(MT)


MUG

MT 707 CR 000833 3 No

Create new extension message MT 708

The redesign of the MT 707 Amendment to a Documentary Credit callsfor a new extension message, which is this MT 708.

MT 707 CR 000848 3 No

Redesigned MT 707 Amendment to a Documentary Credit

The MT 707 has been completely redesigned to be a mirror image ofthe MT 700 Issue of a Documentary Credit. This way, any field presentin the MT 700 can be amended using the MT 707. Codes have beenadded to specify which changes are being made in free format fields.

MT 707 CR 000340 2+ No

Add f ield 45A, 46A and 47A as opt ional fields in MT 707, and addSequence Of Total, so that mu ltiple MT 707 messages can be sentfor one amendment.

As part of an amendment, allow full replacement text to be provided forthe fields 45A Description of Goods and/or Services, 46A DocumentsRequired and 47A Additional Conditions.

MT 730

MT 752

CR 000821 2+ No

Add f ield 79 Narrat ive in MT 730 Acknowledgement and MT 752

Author isation to Pay, Accept or Negot iate

To accommodate information that does not fit in the structured fields ofthis message.

MT 734 CR 000651 1 No

Strictly align the codes and definitions in field 77B Disposal ofDocuments with UCP 600.

Align field with UCP 600.

MT 734

MT 750

MT 754

CR 000815 2- No

Use z character set in f ield 73 Charges



35/42


21 November 2014 35

MessageTypes(MT)


MUG

MT 734

MT 750

MT 754

CR 000816 2- No

Use z character set in fields 77J Discrepanc ies, 77B Disposal ofDocuments and

77A Narrative


MT 760 CR 000847 3 No

Create a new message MT 761 Demand Guarantee/Standby Letterof Credit Issuance Extension

This message is sent in addition to an MT 760 Guarantee/StandbyLetter of Credit message, when the information in the undertakingexceeds the maximum message size of the MT 760.

This message may specify the terms and conditions of the undertakingand for a counter-undertaking and may specify the requested terms andconditions of the local undertaking. Up to eight MT 761 messages maybe 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, thecommunity has asked for this message to be completely redesigned toprovide structured fields, for better automation, STP, limit controls etc.

MT 767 CR 000850 3 No

Redesigned MT 767 Guarantee/Standby Letter of CreditAmendment

The MT 767 Amendment needed to be completely redesigned, giventhe redesign of the base message MT 760.

MT 768

MT 769

CR 000852 2+ No

Add new f ield, Fi le Identif ication, to ident if y locat ion of

attachments

For guarantees and standbys, there is often a need to transmit otherdocuments (letter of guarantee, cover letter, etc.), these can be sent byanother channel, but a reference is needed in the message. This newfield is the same as the one present in the MT 798 trade messages forcorporate to bank communication.


36/42



7 Rejected and Withdrawn Change RequestsThese changes were rejected by a maintenance working group or withdrawn by the submitter.

MessageTypes(MT)


MUG

Cat 1

Cat 2

Cat 9

CR 000754 2+ NA

Reverse the decision reflected in CR 000653 PART 2, to removethe free format options from field 50a Ordering Customer and field59a Beneficiary Customer.

In order to meet the requirements of the Russian legislation, theRussian banking community worked out a fixed structure for fields 50Kand 59 no letter option, which helps to automate the processing ofRussian Rouble MTs 103. For compliance and cost-efficiency reasons,this structure must stay.

MT 102

MT 102STP

MT 103

MT 103REMIT

MT 103STP


MT 103REMIT

MT 102

Add a thi rd mandatory subf ield to f ield 71F Sender s Charges tohold the BIC of the party that took the charges indicated in th isfield.

To increase transparency in the payment chain and to show whichparty deducted each of the charges. It will also decrease the number ofinquiries initiated in respect of unknown/unrecognisable charges.

MT 102

MT 102

STPMT 103

MT 103REMIT

MT 103STP

MT 104

MT 107

CR 000767 2- YesExcept

MT 103MT 103

STP

MT 102STP

Add an optional code word to ident if y consumer credit transfers.

To accommodate the US Dodd Frank 1073 regulation and to be able toindicate that a payment is a consumer credit transfer.


37/42

Rejected and Withdrawn Change Requests

21 November 2014 37

MessageTypes(MT)


MUG

MT 102

MT 102STP

MT 103

MT 103REMIT

MT 103STP

MT 202

MT 202COV

MT 205

MT 205COV


MT 102

MT 103

REMIT

Add codes to f ield 13C Time Ind ication in Payments messages.

To align the documentation with well-known business implementationsand to be able to incorporate these codes in the 'like for like'implementation of ISO 20022 messages for high value payments.

MT 102

MT 103

MT 103REMIT

MT 104

MT 107

MT 110

MT 195

MT 199

MT 200

MT 201

MT 202

MT 202

COVMT 203

MT 204

MT 205

MT 205COV

MT 295

MT 299


MT 104

MT 107

MT 204

MT 102

MT 103REMIT

Change the format and validation of reason codes in PaymentReject/Return Guidelines.

To support coexistence and migration by allowing the use of the ISO20022 external code list for return reason codes.

MT 103

MT 202COV

CR 000753 2+ No

Make field 70 Remittance Information mandatory.

To comply with regulatory AML requirements that mandate the

presence of remittance information and increase transparency.


38/42



MessageTypes(MT)


MUG

MT 202

MT 203

MT 205

CR 000762 2+ No

Add an optional f ield to the interbank payment transfer messagesto indicate the details of the charges contained/settled in themessage.

To provide details of the amount settled, as a result of an MT 191request, in the Payment transfer messages without creating new non-STP claims.

MT 300 CR 000788 2+ No

Add a network validated rule for non-del iverable forwards.

To enhance usage rules for non-deliverable forwards.

MT 300

MT 305

CR 000787 2+ No

Make field 77H Type, Date, Version of the Agreement mandatory inthe MT 300 Foreign Exchange Conf irmation and MT 305 ForeignCurrency Option Confirmation.

To be consistent with ISDA recommendations.

MT 502

MT 509

MT 515

CR 000811 1 No

Update the documentation of the code "SUBS" for qualifier"BUSE" of the field 22a "Indicator".

To clarify the use and the definitions of the "Buy/Sell" qualifier.

MT 535

MT 536

MT 537

MT 540

MT 541

MT 542

MT 543

MT 544

MT 545

MT 546

MT 547

MT 548

CR 000742 2+ No

Add a col lateral pledge in field 22F, quali fier STCO Sett lementTransaction Condition Indicator, that should be used with either22F::SETR//COLI (broker owned) or 22F::SETR//COLO (clientowned) collateral code words.

To allow "hard" collateral pledge and to satisfy CCPs' regulatoryrequirements for segregating collateral.


39/42


21 November 2014 39

MessageTypes(MT)


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


sese.038

sese.039

Add codes for registration basis in di rect holding countries , infield 22F, qualif ier SETR (Type of Settlement TransactionIndicator).

To comply with regulatory requirements.

MT 540

MT 541

MT 542

MT 543

CR 000737 0 No

In field 20C Reference, ASFR Account Servicer Reference, add themissing reference qualifiers MITI Market InfrastructureIdentification and PCTI Processor Transaction Identification.

To improve STP in the context of T2S.

MT 540

MT 541

MT 542

MT 543

MT 544

MT 545MT 546

MT 547

CR 000740 2+ No

Add a new sequence "Reporting Informat ion" .

To comply with regulatory reporting requirements.

MT 558 CR 000809 2+ Yes

Add a new qual if ier ACDR to field 19A Amount in sequence AGeneral Information.

To be able to report the status of DBV transactions back to theinstructing party.

MT 564

MT 566

CR 000766 2+ No

Add opt ional , non-repet it ive quali fier SRCI Country o f IncomeSource in the new 94C Place field , in sequence E2 Cash Movementof MT 564 Corporate Action Noti fication and in sequence D2 CashMovement of MT 566 Corporate Action Confi rmation .

To make it possible to indicate a source country for cash payment so asto be able break out the payment rates per source country instead ofindicating this in narrative fields.


40/42


41/42


21 November 2014 41

MessageTypes(MT)


MUG

MT 600 CR 000648 2+ No

Add an exercise f ield and a f ix ing f ield for cash sett led forward.

To enable cash settled transactions for commodities.

MT 900 CR 000749 2+ No

Allow for non-f inancial institut ions to be identi fied as a separateparty in MT 900.

To be able to identify all parties involved in the payment, particularly ina relay scenario, where the account owner, may be different from thereceiver.

MT n99 CR 000768 2- No

Publish an optional code list f or sanctions, compliance and fraudin the optional field 113 Banking Priority, which is found in theUser Header block (block 3) of the message. Make existing codesin field 75 Queries and field 76 Answers field specific/less generic.

To create easy 'fraud alerts' and prioritise investigations related toregulatory inquiries/sanctions screening, which will reduce theinvestigation processing time and the number of investigationmessages.


42/42


Legal Notices

Copyright

SWIFT 2014. All rights reserved.

DisclaimerThis publication constitutes advance information only and is not to be considered the final and completestandards documentation for the subject matter published herein. The information in this publication maychange from time to time. You must always refer to the latest available version.

SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License

Agreement

SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR Policy -End-User License Agreement, available atwww.swift.com> About SWIFT > Legal > SWIFT StandardsIPR Policy.

Translations

The English version of SWIFT documentation is the only official version.

Trademarks

SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: theSWIFT logo, SWIFT, SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo,MyStandards, and SWIFT Institute. Other product, service, or company names in this publication aretrade names, trademarks, or registered trademarks of their respective owners.
http://www.swift.com/http://www.swift.com/http://www.swift.com/http://www.swift.com/

Swift Standards Infopaper

Documents

Transcript of Swift Standards Infopaper