Message Reference Guide - Yola

1 SWIFTS tandardsCategory 7 - Documentary Credits and GuaranteesFor SWIFTS tandards MT November 2006 Message Reference Guide11 September 2006 This Reference Guide contains the category 7 Message text standards, including a detailed description of the scope, the format specifications, the rules, the guidelines, and the field specifications of each Message may copy this publication within your organisation. Any such copy must include these legal publication contains swift or third-party confidential information. Do not disclose this publication outside your organisation without the prior written consent of supplies this publication for information purposes only. The information in this publication may change from time to time. You must always refer to the latest available English version of swift documentation is the only official and PatentsSWIFT, , the swift logo, Sibos, SWIFTNet, SWIFTA lliance, SWIFTS tandards, SWIFTR eady and Accord are trademarks of SCRL.

2 Other swift -derived service and product names, including SWIFTS olutions, SWIFTW atch and SWIFTS upport, are tradenames of SCRL. swift is the trading name of SCRL. Other product or company names in this publication are tradenames, trademarks, or registered trademarks of their respective September 2006 Table of Contents11 September 2006iiiTable of ContentsIntroduction .. 1 Part 1 - Documentary CreditsDocumentary Credit Message 6MT 700 Issue of a Documentary Credit .. 8MT 701 Issue of a Documentary Credit .. 28MT 705 Pre-Advice of a Documentary Credit .. 33MT 707 Amendment to a Documentary Credit .. 43MT 710 Advice of a Third Bank's or a Non-Bank's Documentary Credit .. 60MT 711 Advice of a Third Bank's or a Non-Bank's Documentary Credit .. 81MT 720 Transfer of a Documentary Credit.

3 86MT 721 Transfer of a Documentary Credit .. 108MT 730 Acknowledgement .. 113MT 732 Advice of Discharge .. 121MT 734 Advice of Refusal .. 126MT 740 Authorisation to Reimburse .. 133MT 742 Reimbursement Claim .. 143MT 747 Amendment to an Authorisation to Reimburse .. 153MT 750 Advice of Discrepancy .. 160MT 752 Authorisation to Pay, Accept or Negotiate .. 167MT 754 Advice of Payment/Acceptance/Negotiation .. 177MT 756 Advice of Reimbursement or Payment .. 186 Part 2 - GuaranteesGuarantee Message types .. 196MT 760 Guarantee .. 197MT 767 Guarantee Amendment .. 204MT 768 Acknowledgement of a Guarantee Message .. 211MT 769 Advice of Reduction or Release .. 222 Part 3 - Common GroupCommon Group Message types .. 232MT 790 Advice of Charges, Interest and Other Adjustments.

4 233 Category 7 - Documentary Credits and Guarantees for SWIFTS tandards MT November 2006ivMessage Reference GuideMT 791 Request for Payment of Charges, Interest and Other Expenses .. 234MT 792 Request for Cancellation .. 235MT 795 Queries ..236MT 796 Answers .. 237MT 798 Proprietary Message .. 238MT 799 Free Format Message .. 239 Glossary of Terms ..240 Introduction11 September 20061 IntroductionOverviewCategory 7 supports messages which are exchanged between banks involved in the documentary credit and guarantee the principles of the ICC UCP, the rules and basic text of these Message types are given in English. Users are however, free to use any language they choose for individual credits and parts sending messages in this category, the following general rules apply: the cancellation of a documentary credit, an authorisation to reimburse, or a guarantee, take the form of an amendment.

5 An MT 792 Request for Cancellation must therefore not be used, but rather an MT 707 Amendment to a Documentary Credit, MT 747 Amendment to an Authorisation to Reimburse, or MT 767 Guarantee Amendment, :The examples used in this category do not always use the total number of characters available for a swift Message or specific field. In some cases, multiple messages are shown, eg, MT 700/701, to demonstrate the use of these messages/fields when the maximum input Message length/field length is volume incorporates the following change to Category 7 - Documentary Credits and Guarantees as noted in the Standards Release Guide (SRG) 2006 and the relevant updates to the SRG 2006: addition of fields and format options to support the advice and transfer of non-bank issued Letters of Credit, transportation details and adherence to market practice rulesIMPORTANTThis volume contains information effective as of the November 2006 Standards Release.

6 Therefore the Standards volumes as published on the User Handbook March 2005 edition remain effective until November Formatting ExplanationThis volume of the Standards User Handbook set contains general information about the category and a detailed description of each Message type which is currently available for use. For each Message type, the following information is provided: Message Type ScopeThe scope specifies the Sender and Receiver of the Message and provides an explanation on how the Message is used. In some messages, an example of the Message flow is also Type Format SpecificationsThe format specifications are the rules for the layout of the Message type. This information is provided in table form with the following information:Category 7 - Documentary Credits and Guarantees for SWIFTS tandards MT November 20062 Message Reference GuideMT nnn ( Message Type Name) MT nnn ( Message Type Name) provides the Message type number and name Status indicates if the field is-M Mandatory-O OptionalThe status M for fields in optional (sub)sequences means that the field must be present if the (sub)sequence is present and is otherwise not allowed.

7 Ta g is the field identification. Field Name is the detailed name of the field tag, for this Message type. Content/Options provides permitted field length and characteristics. For information concerning field structure, notation and character restrictions, please see Standards General Information. No. identifies the number of the field in the Field Specifications for the Message messages are separated into sequences of fields, as shown above. An arrow indicates that a sequence of fields may be Network Validated RulesNetwork validated rules are validated on the network, ie, rules for which an error code is defined. Rules specified in this section affect more than one field in the Message , placing a condition on one of the fields specified. They are identified as Cn, or conditional Usage RulesUsage rules are not validated on the network, ie, rules for which no error code is defined, but are nevertheless mandatory for the correct usage of the Message .

8 Rules specified in this section affect more than one field in the Message , or more than one swift Reference Number16x1M21 Related Reference16x2 Mandatory Sequence A (Sequence Name)M25 Account Identification35x3M32aValue Date, Currency Code, AmountC or D4-----> Optional Repetitive Sequence B (Sequence Name)O52aOrdering InstitutionA or D5M71 BDetails of Charges6*35x6O72 Sender to Receiver Information6*35x7-----|M = Mandatory O = OptionalIntroduction11 September 20063MT GuidelinesGuidelines are not validated on the network and are not mandatory for the correct usage of the Message . They concern good practices. Guidelines specified in this section affect more than one field in the Message , or more than one swift Field SpecificationsThe rules for the use of each field in the Message are specified in this section.

9 Each field is identified by its index number (as shown in the No. column of the MT Format Specifications), field tag and detailed field name, followed by a description of the field, which may contain some or all of the following: FORMAT specifies the field formats which are allowed for the field. PRESENCE indicates if the field is mandatory, optional or conditional in its sequence. DEFINITION specifies the definition of the field in the Message type. CODES lists all codes available for use in the field. If there is more than one subfield for which codes are defined, each separate code list will be identified with a CODES heading. When a list of codes is validated by the network, the error code will be specified. NETWORK VALIDATED RULES specifies rules that are validated on the network, ie, rules for which an error code is defined.

10 Generally, rules specified in this section affect only the field in which they appear. In some cases, rules which are validated at the Message level, ie, rules which affect more than one field, are repeated in this section. This is the case when the rule does not affect the presence of the field, but information within several fields, eg, a currency which must be the same for more than one field in the Message . USAGE RULES specifies rules that are not validated on the network, ie, rules for which no error code is defined, but are nevertheless mandatory for the correct usage of the field. Rules specified in this section affect only the field in which they appear. EXAMPLES provides one or more examples of the field as it will be MappingMT mapping provides an explanation of how to map the fields of the Message into another swift Message , either of the same or a different Message ExamplesExamples are provided to illustrate the correct use of a Message .