MT Forms

Solutions
SWIFT for Corporates
Standards MT Message Implementation Guide

This document describes the rules you must follow when you send or receive Standards MT using SWIFTNet FIN in SCORE (Standardised Corporate Environment).
17 December 2008
Table of Contents
Preface ............................................................................................................................................. 3 1 General Information............................................................................................................... 4 1.1 General Information on BICs and BEIs...................................................................................4 1.2 General Information on IBANs ................................................................................................4 Cash Management Standards...............................................................................................5 2.1 Payment Initiation....................................................................................................................6 2.2 Exceptions Handling and Investigations ...............................................................................27 2.3 Account Reporting.................................................................................................................30 Treasury Markets Standards...............................................................................................44 3.1 MT 300 Foreign Exchange Confirmation ...........................................................................44 3.2 MT 320 Fixed Loan/Deposit Confirmation .........................................................................47 3.3 MT 305 Foreign Currency Option Confirmation.................................................................52 Securities Standards ...........................................................................................................55 4.1 Settlement, Status and Allegement Messages .....................................................................56 4.2 Reconciliation Messages ......................................................................................................64 4.3 Asset Servicing Messages....................................................................................................73 Trade Standards .................................................................................................................. 81 5.1 Import Documentary Credit Transactions .............................................................................89 5.2 Export Letter of Credit Transactions ...................................................................................134 5.3 Guarantee / Standby Letter of Credit Transactions ............................................................163 5.4 Free Format Messages .......................................................................................................234
Legal Notices ............................................................................................................................... 244
Standards MT Messages Implementation Guide
Preface
Preface
Purpose of this document
The purpose of this document is to document how the FIN standards must be implemented and used between corporates and financial institutions. It sets out those standards (also called Message Types or MTs) that are suitable for this purpose and provides usage rules and guidelines to ensure their consistent implementation. Participants in the SCORE service are expected to adhere to the rules in this document. Where messages are exchanged in a MA-CUG or other SWIFT environment, adherence to these rules must not be assumed. Note SCORE participants are not required to support all messages, all message functionality and usage in this document, but where they do, these rules must be followed.
This guide is not a standards handbook. The detailed description of the FIN standards can be obtained from the SWIFT User Handbooks, Category Volumes. Where applicable, this guide refers to those handbooks.
Document structure
This guide is structured as follows:
Section 1: provides information about the notions of BIC (Bank Identifier Code), BEI (Business Entity Identifier), and IBAN (International Bank Account Number) Section 2: covers the use of the cash management standards (CAT 1, CAT 2 and CAT 9) Section 3: deals with treasury markets standards (CAT 3) Section 4: deals with securities markets standards (CAT 5) Section 5: deals with trade markets standards (CAT 7)
Wherever possible, business scenarios and examples are provided to best illustrate how the standards must be used. This document uses the following typographical conventions:
Bold Names of files, parameters, API calls, user logon, and logon groups References to a directory or a menu GUI elements and command names Italics Courier Underline Strikethrough Important information and document names User input, directory paths, parameter values, place holders, and system output examples Added rule/guideline compared to the previous release of the document Deleted rule/guideline compared to the previous release of the document
17 December 2008
1
1.1
General Information
General Information on BICs and BEIs
A BIC (Bank Identification Code) is an identifier that is assigned to all SWIFT FIN-connected financial institutions. It can also be used to identify other financial institutions, not connected to the SWIFT FIN network. The scope of this code has been extended to identify non-financial organisations as well, including corporates. When assigned to a non-financial institution the code is called a BEI (Business Entity Identifier). Like a financial institution BIC, a non-financial institution BEI can be connected to the SWIFT FIN network or not. The difference between financial institutions and non-financial institutions becomes particularly important when a party in a transaction is identified. A financial institution can typically service accounts and own accounts. A non-financial institution (for example, corporate) can only own accounts. This is a key difference in any message that implies settlement of funds. This is also the reason why in all SWIFT FIN standards messages, some fields may contain a BIC or a BEI, whilst other fields are restricted to BIC only, or to BEI only. Corporates receive a BEI. Such a BEI is fully registered in the BIC database. The SWIFT FIN network validates all party fields in the FIN messages on the presence of the appropriate BIC or BEI.
1.2
General Information on IBANs

For accounts serviced in countries that have implemented IBAN (International Bank Account Number), the IBAN should be used to identify the account, regardless of the message type
Standards MT Messages Implementation Guidelines
Cash Management Standards

SWIFT offers a range of FIN standards - also called Message Types (MTs) - to initiate credit transfers and direct debits. A related set of standards is available to handle status reporting (rejections) and deal with exceptions and investigations. There are also standards that provide account related information exchanged between an account owner and an account servicing institution for cash management and reconciliation purposes.
The following section explains the above cash management related MTs, and provides a series of guidelines facilitating the common usage of those message types. A set of business examples is provided at the end of this section. Update History The following updates were applied to these guidelines as part of the 17 December 2008 update and are effective as of the 21 November 2009 Standards Release: 1. 2. General Information: Added general information on the use of IBAN. MT 101 Field 50a (Ordering Customer): Added a usage rule to indicate that a bank should accept as the ordering customers account number in field 50F, 50G or 50H, the account number that the bank provides themselves in field 25 (Account Identification) of the MT 940. MT 101 field 23E (Instruction Code): Modified usage rule to indicate that a bank must be able to accept the code 'URGP' in field 23E to indicate a payment with a priority of urgent, however the specific usage and interpretation of this and the other instruction codes depends on the agreement between the sender and receiver.
3.
17 December 2008
4. 5. 6. 7.
MT 101 field 56a (Intermediary): Added a usage guideline with a definition of 'Intermediary Bank'. MT 101 field 77B (Regulatory Reporting): Added a usage guideline with a list of recommended codes for use in this field. MT 103, Customer Credit Transfer: Deleted from SCORE. MT 199 field 21 (Related Reference): Added a usage guideline to indicate that when the MT 199 is related to a previously sent or received SWIFT MT message, this field should contain field 20 (Transaction Reference Number) of the original MT message. MT 900 Field 72 (Sender to Receiver Information): Added a usage guideline with a recommended code for use in this field to indicate the clearing system identification. MT 942 Field 86 (Information to Account Owner): Added a usage guideline with a recommended code for use in this field to indicate the clearing system identification.
8. 9.
2.1
Payment Initiation
The SWIFT User Handbook, Volume Standards Category 1, Customer Payments and Cheques serves as the main document describing the standards. For more information, see this handbook.
2.1.1
MT 101 Request for Transfer

The MT 101 is sent by the corporate to the financial institution. It is used to move funds from the ordering customers account, serviced at the receiving financial institution or at the account servicing institution.
Scope
Usage
The MT 101 can contain one or more payment transactions. The sender of the MT 101 can ask for batch booking (one single debit entry) or transaction booking (one debit entry per transaction included in the MT 101). The MT 101 can be used to order the movement of funds, either domestically or internationally:
between ordering customer accounts in favour of a third party
The account servicing bank can be the receiver of the message (see direct scenario), or can be a party further in the payment chain (see relay scenario):
Direct scenario
A customer orders its bank to instruct a payment from its account with that bank:
The receiving bank debits the account and initiates a credit transfer (in its books or by forwarding an MT102/103 or local credit transfer message).
Relay scenario
A customer orders its bank to instruct a payment from its account with a second bank:
The receiving bank forwards the MT 101 to the account servicing institution. This institution will debit the customers account and initiate a credit transfer (in its books or by forwarding an MT102/103 or local credit transfer message).
Customer parties in the MT 101

The MT 101 can be sent by the account owner (identified in the MT 101 as ordering customer) or by another party authorised to order the debit of the ordering customers account. Agreements between the customer parties and the receiving bank must be in place. The following diagram shows which customer parties can be identified:
17 December 2008
Notes:
In case 2 and 3, the actor head-office can be one and the same as payments factory or shared service centre. The roles illustrated in the diagram also apply to the relay scenario.
The different scenarios are illustrated in the Business Examples section.
Message usage guidelines

The SWIFT User Handbook, Volume Standards Category 1, MT 101 Request for Transfer contains full field specifications and network validated rules that must be adhered to. In order to facilitate the use of the MT 101 for corporate-to-bank usage, some additional usage rules and guidelines have been defined. A rule must be adhered to, whereas a guideline is a recommendation, a best practice that must be followed whenever possible.
Sender / Field 50 C or L Instructing Party / Field 50 G, H or F Ordering Customer UHB definition Ordering Customer: This field identifies the account owner whose account is to be debited. Instructing Party: This field identifies the customer which is authorised by the account owner/account servicing institution to order all the transactions in the message. Usage rule for Instructing Party: This field must only be used when the instructing party is not also the account owner. Additional usage rules For sender/ordering customer: If the sender of the MT 101 is also the account owner, the sender will appear in the Message Header as sender and will also be included as field 50 G, H or F Ordering Customer in the Text part of the Message (case 2). For sender/instructing party: If the sender of the MT 101 is the Instructing Party (is not the account owner, but has the authority to order the debit of the ordering customers account and is the originator of the payment), the sender is repeated in field 50 C or L Instructing Party (case 3). For instructing party: If the instructing party is neither account owner (=ordering customer) nor sender, it has to be mentioned in field 50C or L Instructing party (case 4). Field 50 G, H or F Ordering Customer> Acceptance of account number UHB definition Ordering Customer: This field identifies the account owner whose account is to be debited. Usage rule: Both the account number of the ordering customer at the Receiver or at the account servicing institution and the name and address or the BEI of the ordering customer must be present. Additional usage rule [rule applicable as from 21 November 2009] A bank should accept as the ordering customers account number in the MT101, field 50F, 50G or 50H depending on bank requirements, the account number that the bank provides themselves in field 25 (Account Identification) of the MT 940, with the same format, length and representation.
Field 30 Requested Execution Date> Interpretation of date
UHB definition
This field specifies the date on which all subsequent transactions must be initiated by the executing bank. Usage rule: This is the date on which the ordering customers account(s) is (are) to be debited.
Additional usage rule
Any other usage or interpretation of this field must be bilaterally agreed between the sender and the receiver.
Field 23E Instruction Code> Interpretation of codes UHB definition Additional usage rule [rule applicable as from 21 November 2009] This field specifies instructions for the account servicing institution of the ordering customer. The usage and interpretation of the codes depends on the agreement between the sender and receiver. A bank must be able to accept the code URGP to indicate a payment with a priority of urgent, however the specific usage and interpretation of this and the other instruction codes depends on the agreement between the sender and receiver.
Field 56a: Intermediary UHB definition This field specifies the financial institution through which the transaction must pass to reach the account with institution. Usage Rule: The intermediary may be a branch or affiliate of the Receiver or the account with institution, or an entirely different financial institution. Additional usage guideline [guideline applicable as from 21 November 2009] Definition: Intermediary Bank means the bank through which the funds will be transferred to the Beneficiarys Bank (Account with Institution). In those instances where the Beneficiary's Bank (Account with Institution) has a preferred Intermediary Bank, the Ordering Customer would specify these details in the Intermediary Bank field. In all other instances the Intermediary Bank field must not be specified by the Ordering Customer. Refer also to business example 5 (Settlement via Intermediary Bank). Field 70 Remittance Information> Inclusion of end-to-end customer information UHB definition This field specifies details of the individual transactions which are to be transmitted to the beneficiary customer. One of the following codes may be used, placed between slashes: INV Invoice followed by the date, reference and details of the invoice IPI Unique reference identifying a related International Payment Instruction (followed by up to 20 characters) RFB Reference for the beneficiary customer (followed by up to 16 characters) ROC ordering customers reference Usage rules: For national clearing purposes, the sender must check with the receiver regarding length restrictions of field 70. The information specified in this field is intended only for the beneficiary customer. This information only needs to be conveyed by the receiver. Multiple references can be used, if separated with a double slash, //. Codes must not be repeated with between two references of the same kind.
17 December 2008
Additional usage guideline
Information that needs to be passed on end-to-end (through to the beneficiary customer) must be included in field 70 Remittance Details by the sender of the MT 101. In addition to one of the codes defined in the UHB, one or more of the following codes can be used by the sender to identify parties: /ULTB/: identification of the ultimate beneficiary customer (when different from the beneficiary customer) /INST/: identification of the instructing party (when different from the ordering customer)
Note: Even though the instructing party can be included as dedicated field in the MT 101 (50C or L Instructing party), current interbank customer credit transfer messages may not be able to transport this dedicated field. If transport of this party in the interbank chain is required, it is suggested to include the instructing party also in field 70 of the customer-to-bank MT 101. As stated in the usage rules documented in the UHB, the sender must check with the receiver regarding length restrictions of field 70. Note: The end-to-end customer reference must be included after /ROC/ as specified in the UHB. Field 77B: Regulatory Reporting UHB definition This field specifies code(s) for the statutory and/or regulatory information required by the authorities in the country of the Receiver or the Sender/originating customer. Usage Rule: Country consists of the ISO country code of the country of residence of the ordering customer or beneficiary customer. Additional usage guideline [guideline applicable as from 21 November 2009] To enable consistent handling of regulatory reporting entities in jurisdictions where this information is relevant in regulatory reporting the following codes and structures may be used: TAXIDNUM Tax Identification Number The code placed between slashes ('/'), must be followed by the ISO country code, a double slash ('//'), and the Tax Identification Number. BENEFRES Beneficiary Country Code The code placed between slashes ('/'), must be followed by the ISO country code. or Beneficiary Residence The code placed between slashes ('/'), must be followed by the ISO country code, a double slash ('//'), and up to three address lines, each line separated by a double slash ('//'). ORDERRES Ordering Customer Country Code The code placed between slashes ('/'), must be followed by the ISO country code. or Ordering Customer Residence The code placed between slashes ('/'), must be followed by the ISO country code, a double slash ('//'), and up to three address lines, each line separated by a double slash ('//').
10
Business Examples
Please note that for each of the following examples, the assumption is that appropriate agreements have been put in place between the different customer parties and the receiving banks to execute the transfers requested.
1A. Head office paying from own account on behalf of multiple subsidiaries and itself direct scenario
This example is based on case 2 of the customer parties scenarios as shown in the Usage section of the MT 101: the head office is the account owner and sends the MT 101 message on behalf of its subsidiary (= the Instructing party) as illustrated below:
Narrative
PlantOil has concentrated its treasury cash management functions in its head office, PlantOil Company (PLATUS33) in Los Angeles, California. All wire transfer transactions ordered by PlantOils subsidiaries such as PlantOilAxim, PlantOilProductions are sent by PlantOil Company to its various banks, where PlantOil Company holds master concentration accounts. As the transactions are in USD, PlantOil sends the MT 101 to its USD bank, AAAAUS33.
Scenario
Account number at AAAAUS33 (to debit): 1234567891 Account owner PlantOil Company Subsidiaries: PlantOilAxim, PlantOilProductions Payment details:
On behalf of PlantOilAxim, for 118,982.05 USD to Wung Lu Manufacturing at BBBBCNBJ (account number 60648929889) in Beijing, China. Payment is for invoices. PLATUS33 has sent a separate remittance advice (with reference RA-PL-9876-87) providing information on the invoices paid to Wung Lu. On behalf of PlantOilProductions, for 50,000 USD, to Tristan Recording Studios at CCCCGB2L (account 0010499) in London, GB. Payment is for invoices. PLATUS33 has sent a separate remittance advice (with reference RA-PL-9876-103) providing information on the invoices paid to Tristan Recording Studios. On behalf of PlantOil Company, for 377,250 USD, to River Paper Company at DDDDUS33 (account number 26351-38947) in San Francisco, CA, US. Payment is for invoices AUG06345 and AUG06-346. With this supplier, PLATUS33 does not exchange separate remittance advices.
PlantOil would like to see 1 batched entry on its account for the different transactions.
17 December 2008
11
Information flow
SWIFT message
Explanation Header Sender Message Type Receiver Message text Sequence A General Information Senders Reference Customer Specified Reference* Message Index/Total Ordering Customer** Requested Execution Date Repetitive Sequence B - Transaction Details 1 Transaction Reference Currency/Transaction amount Instructing Party Account With Institution :21:TR1-PL :32B:USD118982,05 :50L: PLANTOIL AXIM :57A:BBBBCNBJ :59:/60648929889 WUNG LU MANUFACTURING 23 XIAN MEN WAI AVE BEIJING :70:/ROC/RA-PL-9876-87 /INST/PLANTOIL AXIM :71A:SHA :20:PLANT-12345 :21R:PLTOL101-56 :28D:1/1 :50G:/1234567891 PLATUS33 :30:060929 PLATUS33 101 AAAAUS33 Format
Beneficiary
Remittance Information*** Details of charges Repetitive Sequence B - Transaction Details 2
12
Transaction Reference Currency/Transaction amount Instructing Party Account With Institution
:21:TR2-PL :32B:USD50000, :50L:PLANTOIL PRODUCTIONS :57A:CCCCGB2L :59:/0010499 TRISTAN RECORDING STUDIOS 35 SURREY ROAD GB-BROMLEY, KENT :70:/ROC/RA-PL-9876-103 /INST/PLANTOIL PRODUCTIONS :71A:SHA
Beneficiary
Remittance Information*** Details of charges Repetitive Sequence B - Transaction Details 3 Transaction Reference Currency/Transaction amount Instructing Party Account With Institution
:21:TR3-PL :32B:USD377250, :50L:PLANTOIL COMPANY :57A:DDDDUS33 :59:/26351-38947 RIVER PAPER COMPANY 37498 STONE ROAD US - SAN RAMON, CA :70:/INV/AUG06-345//AUG06-346 :71A:SHA
Beneficiary
Remittance Information**** Details of charges
Notes:
* = field 21R Customer Reference is used to indicate that the customer requests a single debit entry (batch booking) for all the transactions contained in the MT 101. ** = as the same account will be used to book all transactions, the ordering customer can be quoted in Sequence A General Information. If different accounts had to be used, the ordering customer (and its account) would be included in Sequence B Transaction Details. *** = as included in the Message Usage Guidelines, field 70 Remittance information contains information that needs to be passed on end-to-end. For transaction 1 and 2, PLATUS33 has included an end-to-end reference (after code /ROC/ = reference of the ordering customer) which, in this example, is the ID of the remittance advice which was sent separately from the payment. PLATUS33 can also repeat the instructing party preceded by code /INST/ in this field - as it is not always possible to transport the dedicated Instructing Party field in the interbank clearing and settlement part of the chain. As PlantOil Axim and PlantOil Productions are the original receivers of the invoices, this information may be useful to allow reconciliation by the beneficiary customer. For transaction 3, PLATUS has included the invoice numbers (after code /INV/=invoices). **** = for this last transaction, the ordering customer equals the instructing party. In this case, it is not mandatory to include the instructing party.
17 December 2008
13
1B. Head office paying from own account on behalf of multiple subsidiaries and itself relay scenario Narrative
The example illustrated above (under 1A) can also be used in a relay scenario (provided such a scenario has been agreed between all relevant parties). In this case, PlantOil sends an MT 101 to AAAAUS33 and requests AAAAUS33 to forward the MT 101 to the bank that holds PlantOils account (999777) to be debited (=Customers Account Servicing Institution, for example. ZZZZUS33). The message would be exactly the same as the one illustrated above, with the addition of field 52A Account Servicing Institution in Sequence A General Information to identify the Account Servicing Institution. Information flow
SWIFT message
Explanation Header Sender Message Type Receiver Message text Sequence A General Information Senders Reference Customer Specified Reference Message Index/Total Ordering Customer :20:PLANT-12345 :21R:PLTOL101-56 :28D:1/1 :50G:/999777 PLATUS33 PLATUS33 101 AAAAUS33 Format
14
Account Servicing Institution Requested Execution Date
:52A: ZZZZUS33 :30:060929
Notes:
The transaction details sequences will contain the same content as in example 1A. Upon receipt of this MT 101, AAAAUS33 will then forward the MT 101 to ZZZZUS33. The content of this second MT 101 must be the same. Upon receipt of the MT 101, ZZZZUS33 will debit the account of PLATUS33 and execute the payment.
2A. Head office paying from a subsidiary account direct scenario

This example is based on case 3 of the customer parties' scenarios: head office is the instructing party (the party that needs to make the payment) and has the authority to debit the account of one of its subsidiaries:
Narrative
Springs Inc head office (SPRNGB2L) wants to pay an invoice in GBP from its subsidiarys account. Both Springs Inc head office and Springs branch have accounts at the same bank (AAAAGB2L). Springs Inc head office is authorised to make payments from the accounts of its subsidiaries. Springs Inc head office sends the MT 101 to AAAAGB2L, asking it to debit the account of Springs Brighton branch (9876543).
Information flow
SWIFT messages
Explanation Header Sender Message Type SPRNGB2L 101 Format
17 December 2008
15
Receiver Message text Sequence A General Information Senders Reference Message Index/Total Instructing party*
AAAAGB2L
:20:SPRING-01 :28D:1/1 :50C:SPRNGB2L :50H:/9876543 SPRINGS BRANCH LEICESTER AVENUE GB-BRIGHTON :30:060929
Ordering Customer*
Requested Execution Date Repetitive Sequence B - Transaction Details 1 Transaction Reference Currency/Transaction amount Account With Institution Beneficiary
:21:SPRING-01 :32B:GBP1000, :57A:CCCCGB2L :59:/GB1111111 THOMPSON FACTORY GB-LIVERPOOL :70:/INV/TH9876//TH9877 /INST/SPRINGS INC :71A:SHA
Remittance Information** Details of charges
Notes:
* = as the MT 101 only contains one transaction, ordering customer and instructing party need only to be present once. They are either present in Sequence A General Information, or in Sequence B Transaction Details. **= as included in the Message Usage Guidelines, field 70 Remittance information contains information that needs to be passed on end-to-end. Springs Inc (the sender and instructing party of this MT 101) has included the invoice reference numbers (after code /INV/ = invoice). Springs Inc can also repeat itself, the instructing party, preceded by code /INST/ in this field - as it is not always possible to transport the dedicated Instructing Party field in the interbank clearing and settlement part of the chain. As Springs Inc was the receiver of the original invoice, this information may be useful to allow reconciliation by the beneficiary customer.
2B. Head office paying from a subsidiary account relay scenario Narrative
The example illustrated above (under 2A) can also be used in a relay scenario. Springs Incs branch in Germany holds a EUR account. Head office is centralising all payments, and is authorised to use the accounts of its branches. A payment in euros is to be made.
16
In this case, Springs Inc would send an MT 101 to AAAAGB2L and request AAAAGB2L to forward the MT 101 to the German bank (BBBBDEFF) that services an account (DE89370400440532013000) for the German branch of Springs Inc. to be debited. The message would be exactly the same as the one illustrated above, with the addition of field 52A Account Servicing Institution in Sequence A General Information, to identify BBBBDEFF.
Information flow
SWIFT message
Explanation Header Sender Message Type Receiver Message text Sequence A General Information Senders Reference Message Index/Total Instructing party* :20:SPRING-01 :28D:1/1 :50C:SPRNGB2L :50H:/DE89370400440532013000 SPRINGS BRANCH ZEIL 5 DE-FRANKFURT :52A:BBBBDEFF :30:060929 SPRNGB2L 101 AAAAGB2L Format
Ordering Customer*
Account Servicing Institution Requested Execution Date Repetitive Sequence B - Transaction Details 1 Transaction Reference Currency/Transaction amount Account With Institution Beneficiary
:21:SPRING-01 :32B:EUR1000, :57A:DDDDDEFF :59:/DE12345678912345678912
17 December 2008
17
MULLER DE-FRANKFURT Remittance Information** Details of charges :70:/INV/MLRAB98 /INST/SPRINGS INC :71A:SHA
Upon receipt of this MT 101, AAAAGB2L will then forward the MT 101 to BBBBDEFF. The content of this second MT 101 must be the same. Upon receipt of the MT 101, BBBBDEFF will debit the account of Springs Branch, Frankfurt, and execute the payment.
3A. Shared service centre or payments factory sending the payment instruction
This example is based on case 4 of the customer parties' scenarios: the shared service centre or payments factory sends the MT 101 message; it is not the account owner, nor the instructing party of the payment transactions as illustrated in the following diagram:
Narrative
BioGen head office has concentrated its treasury cash management functions. It concentrates all payments from its branches, and owns master concentration accounts at various banks across the world. In order to send its payment instructions, it uses its shared service centre, BIOGNL2A. Appropriate agreements have been put in place between BioGen head office, BIOGNL2A and the banks servicing the accounts for BioGen. As the transactions are in USD, BIOGNL2A will send the MT 101 to BioGen head offices USD bank, AAAAUS33. At AAAAUS33, BioGen holds 2 accounts: 12345 and 67890. SCENARIO: Sender: Shared Service Centre BIOGNL2A Account numbers at AAAAUS33 (to debit): 12345 and 67890 Account owner: BioGen US Subsidiaries: BioGen France, BioGen Hong Kong Payment details:
On behalf of BioGen France, for 30,000 USD to El Puerto Productions, Mexico, that has account 11111 at BBBBMXMM. BIOGNL2A has sent a separate remittance advice to El Puerto to inform it of the invoices paid with this payment. On behalf of BioGen Hong Kong, for 20,000 USD, to BioWorld, New Jersey, US, that has account 22222 at CCCCUS33. Payment is for three invoices. No separate remittance advices are exchanged with this supplier.
18
BioGen would like to pay transaction 1 from its account 12345, and transaction 2 from its account 67890.
Information flow
SWIFT message
Explanation Header Sender Message Type Receiver Message text Sequence A General Information Senders Reference Message Index/Total Requested Execution Date Repetitive Sequence B - Transaction Details 1 Transaction Reference Currency/Transaction amount Instructing Party Ordering Customer* Account With Institution :21:TR1-BIOG :32B:USD30000, :50L:BIOGEN FRANCE :50H:/12345 BIOGEN US CA-SAN FRANCISCO :57A:BBBBMXMM :59:/11111 EL PUERTO PRODUCTIONS AVENIDA CORAL MEXICO :70:/ROC/BGF89765 /INST/BIOGEN FRANCE :20:BIO-123 :28D:1/1 :30:060929 BIOGNL2A 101 AAAAUS33 Format
Beneficiary
Remittance Information**
17 December 2008
19
Details of charges Repetitive Sequence B - Transaction Details 2 Transaction Reference Currency/Transaction amount Instructing Party Ordering Customer* Account With Institution Beneficiary
:71A:SHA
:21:TR2-BIOG :32B:USD20000, :50L: BIOGEN HONG KONG :50H:/67890 BIOGEN US CA-SAN FRANCISCO :57A:CCCCUS33 :59:/22222 BIOWORLD US-NEW JERSEY,NJ :70: /INV/BW654//BW655//BW656 /INST/BIOGEN HONG KONG :71A:SHA
Remittance Information** Details of charges
Notes:
* = As 2 different account numbers belonging to BioGen US have to be used, the ordering customer is identified in each of the transaction details sequences with the relevant account number to be debited. ** = as included in the Message Usage Guidelines, field 70 Remittance information contains information that needs to be passed on end-to-end. For the first transaction, BIOGNL2A has included an end-to-end reference (after code /ROC/ = reference of the ordering customer) which, in this example, is the ID of the remittance advice which was sent separately from the payment. BIOGNL2A can also repeat the instructing party (BioGen France) preceded by code /INST/ in this field - as it is not always possible to transport the dedicated Instructing Party field in the interbank clearing and settlement part of the chain. For the second transaction, BIOGNL2A provides the invoice numbers and can also include the instructing party (BioGen Hong Kong) preceded by code /INST/.
3B. Shared service center or payments factory sending the payment instruction relay scenario. Narrative
A relay scenario is also possible: in this case BIOGNL2A (sender) will send the MT 101 to a forwarding bank (receiver), and identify the account servicing bank in 52a Account Servicing Institution. If the same account servicing bank is to be used for all transactions, this bank is identified in Sequence A General Information. Information flow
20
Notes:
If a different account servicing bank is to be used depending on the transactions included, the account servicing bank is specified in field 52a Account Servicing Institution of Sequence B Transaction Details. This scenario is technically possible. However, it means that the receiving bank (AAAAUS33) would have to split the MT 101 received into several MT 101s it needs to forward to the different account servicing institutions. The same result could be achieved if the sender (BIOGNL2A) sends a file to AAAAUS33 per account servicing institution. It must be agreed between sender and receiver which scenario they will use. The following diagram illustrates this scenario.
17 December 2008
21
4. Payment made in settlement of a market deal Narrative
On 22 January 2009, OneCapital concludes a spot deal and buys 10,000,000 JPY against USD at 107.833 from Bank of Tokyo, Japan. The JPY are credited to OneCapitals account held at Bank of Tokyo. One day later, OneCapital transfers 927,364 USD to Bank of Tokyo as settlement of the deal. SCENARIO: Account number at CHASUS33 (to debit): 1234567891 Account owner: OneCapital F/X Deal Reference: BOTKJT2736ONCE44 Payment details:
On behalf of OneCapital, for 927,364 USD to be debited from OneCapitals account held with Chase Manhattan Bank and credited to Bank of Tokyo with respect to spot exchange deal number BOTKJPJT4475.
Information flow
SWIFT message Explanation Header Sender Message Type Receiver Message text Sequence A General Information Senders Reference Message Index/Total :20:AA87999BM :28D:1/1 ONECUS44 101 CHASUS33 Format
22
Ordering Customer Requested Execution Date Repetitive Sequence B - Transaction Details 1 Transaction Reference F/X Deal Reference Currency/Transaction amount Beneficiary Details of charges
:50G:/1234567891 ONECUS44 :30:090123
:21:TR1-ONECAP/4475 :21F:BOTKJT2736ONEC44 :32B:USD927364,00 :59A:BOTKJPJT :71A:SHA
5. Settlement via Intermediary Bank Narrative
Fabrista Corporation, a US based retail clothing chain initiates a payment to one of its Indian manufacturers, Tiger Fashions. TigerFashions has their account with a small local bank, ChennaiSun Bank and requests Fabrista Corp to route their payments through the preferred correspondent bank of ChennaiSun Bank, specifically ICICI Bank. ChennaiSun Bank does not have a SWIFT BIC.
Scenario
Account number at CHASUS33 (to debit): 654332101 Account owner: Fabrista Corporation Beneficiary bank: ChennaiSun Bank, 12 Salem Kamir Road, Chennai - 6090091, India Invoice number: TGF001935 Payment details:
On behalf of Fabrista Corp, for 23,333 USD to be debited from Fabrista Corps account held with Chase Manhattan Bank and transferred via ICICI Bank serving as an intermediary to the beneficiarys bank, ChennaiSun Bank.
17 December 2008
23
Information flow
SWIFT message Explanation Header Sender Message Type Receiver Message text Sequence A General Information Senders Reference Message Index/Total Ordering Customer Requested Execution Date Repetitive Sequence B - Transaction Details 1 Transaction Reference Currency/Transaction amount Intermediary Account With Institution :21:TR1-FABB6755 :32B:USD23333,00 :56A:ICICINBB :57D:CHENNAISUN BANK 12 SALEM KAMIR ROAD :20:84549FV :28D:1/1 :50G:/654332101 FABBUS6S :30:090123 FABBUS6S 101 CHASUS33 Format
24
CHENNAI - 6090091 :59:/6069889753 TIGER FASHIONS 65A RAJAJI SALAI CHENNAI - 600001 :70:/INV/TGF001935 :71A:SHA
Beneficiary
Remittance Information Details of charges
2.1.2 MT 103 Customer Credit Transfer

Scope
The MT 103 is sent by the corporate to the financial institution. The MT 103 is less appropriate for corporate-to-bank instructions than the MT 101, Request for Transfer. Compared to the MT 101, the MT 103:
does not allow to identify several customer parties contains mandatory fields and a series of optional fields only relevant for interbank usage only caters for single instructions only caters for direct scenarios (not relay)
NoteThe MT 103 must not be used by an ordering customer to advise the beneficiary customers bank of a future credit to the beneficiary customers account. [deletion applicable as from 21 November 2009 - IMPORTANT NOTE: the MT103 will be removed from SCORE as from 21 November 2009]
2.1.32.1.2 MT 104 Direct Debit and Request for Direct Debit

Scope
The MT 104 is sent by the corporate to the financial institution. It is used to request the direct debit of the debtor's account in the receiver's country and subsequently to credit the creditor's account maintained by the receiver or one of its branches.
Usage
The message must be used in a request for debit transfer scenario. A customer orders its bank to start a direct debit and credit its account with him, or, a customer orders its bank to instruct a direct debit and credit its account with another bank. The account is owned by the customer.
17 December 2008
25
The receiving bank would forward the MT 104 cross-border, or start a domestic direct debit collection.

The SWIFT User Handbook, Volume Standards Category 1, MT 104 Request for Direct Debit contains full field specifications and network validated rules that must be adhered to. In order to facilitate the use of the MT 104 for customer-to-bank usage, some additional usage rules and guidelines have been defined. A rule must be adhered to, whereas a guideline is a recommendation, a best practice that must be followed whenever possible.
Sender / Field 50 C or L Instructing Party / Field 50 A or K Ordering Customer > Repetition of Sender UHB definition Creditor: This field specifies the creditor whose account is to be credited. In case the MT 104 is used under the request for Direct Debit scenario, this account is held at the receiver. Instructing Party: This field specifies the customer which is authorised by the creditor/account servicing institution to order all the transactions in the message. Usage rule for Instructing party: This field must only be used when the instructing party is not also the creditor. Additional usage rules For sender/creditor: If the sender of the MT 104 is also the account owner, the sender appears in the Message Header as sender and is also included as field 50 A or K Creditor in the Text part of the message. For sender/instructing party: If the sender of the MT 104 is the Instructing party (is not the account owner, but is authorised by the account owner to request the direct debit and is the originator of the direct debit), the sender must be repeated in field 50 C or L Instructing party. For instructing party: If the instructing party is neither account owner (=creditor) nor sender, it has to be mentioned in field 50 C or L Instructing party. Field 23E Instruction Code (Sequence A) > Code Request for Direct Debit UHB definition Additional usage rule This field identifies the type of direct debit instructions contained in the message. The only code allowed is RFDD: Request for Direct Debit
Field 70 Remittance Information > Inclusion of end-to-end customer information UHB definition This field specifies details of the individual direct debit which are to be transmitted to the debtor. One of the following codes may be used, placed between slashes: INV Invoice followed by the date, reference and details of the invoice IPI Unique reference identifying a related International Payment Instruction (followed by up to 20 characters) RFB Reference for the Debtor (followed by up to 16 characters) ROC Ordering Customers reference Usage Rules: For national clearing purposes, the sender must check with the receiver regarding length restrictions of field 70. The information specified in this field is intended only for the debtor, this
26
information only needs to be conveyed by the receiver. Multiple references can be used, if separated with a double slash, //. Codes must not be repeated between two references of the same kind. Additional usage guideline) Information that needs to be passed on end-to-end (through to the beneficiary customer) must be included in field 70 Remittance Details by the sender of the MT 104. In addition to one of the codes defined in the UHB, one or more of the following codes can be used by the sender to identify parties: /ULTD/: identification of the ultimate debtor (when different from the debtor) /INST/: identification of the instructing party (when different from the creditor) Note: Even though the instructing party can be included as dedicated field in the MT 104 (50C or L Instructing party), current interbank clearing and settlement messages may not be able to transport this dedicated field. If transport of this party in the interbank chain is required, it is suggested to include the instructing party also in field 70 of the customer-to-bank MT 104. As stated in the Usage Rules documented in the UHB, the sender must check with the receiver regarding length restrictions of field 70.
The use and meaning of several other fields would have to be agreed bi-/multilaterally (for example, charges, exchange rates, codes, and value date).
Business examples
As the implementation of the MT 104 depends on country specific agreements, no business examples are provided.
2.2
Exceptions Handling and Investigations

The SWIFT User Handbook, Volume Standards Category n, Common Group Messages serves as the main document describing the standards. The following text only serves to specify some particular ways of using the messages and to advise on which message must be used for which purpose. The following topics describe Category n messages that are most relevant in the context of corporate payments and cash management.
2.2.1
MT 199 Free Format Message

This message type is normally used by financial institutions to send information for which another message type is not applicable.
Scope
Usage
It can be used as a status message to report reasons for a transaction instruction not being executed or as a message to reject a transaction.
17 December 2008
27

This is a free format message. Field 21 Related Reference contains a reference to the payment initiation message.Field 21 (Related Reference) contains a reference to a related message. When the MT 199 is related to a previously sent or received SWIFT MT message, field 21 should contain field 20 (Transaction Reference Number) of the original MT message. [guideline applicable as from 21 November 2009] It must be agreed between corporate and its financial institution how the reject (identification of the reject, reject reason, and any additional information) will be conveyed in the MT 199.
2.2.2
MT 192 Request for Cancellation

This message type is sent by the corporate to the financial institution. It can be used to request to consider cancellation of the SWIFT message identified in the request.
Scope
Usage
An MT 192 can be sent to request the cancellation of one single transaction contained in the MT 101 or to request cancellation of the complete MT 101. The request for cancellation always requires a response. This can be done through MT 196, or through MT 199 subject to bilateral agreement. It is up to the receiving bank to define its cancellation policies.

The SWIFT User Handbook, Volume Standards Category n, Common Group Messages, n92 Request for Cancellation contains full field specifications and network validated rules that must be adhered to. No specific message usage guidelines have been defined.
28
Business examples
For an example of how the MT n92 can be used, see the SWIFT User Handbook.
2.2.3
MT 195 Queries and MT 196 Answers

This message type can be sent by the corporate to the financial institution. It can also be sent by the financial institution to the corporate. It is used to request information or clarification relating to a previously sent message, or to one or more transactions contained therein. A query may also be sent to request that an amendment be made to a previous message.
Scope MT 195
Usage
MT 195 must not be used to reject a previous message. MT 199 must be used for this purpose. The MT 195 always requires a response. This can be done through MT 196, or through MT 199 subject to bilateral agreement.
Scope MT 196
This message type can be used to respond to an MT 192 Request for Cancellation or MT 195 Queries message.

The SWIFT User Handbook, Volume Standards Category n, Common Group Messages, n95 Queries and n96 Answers contains full field specifications and network validated rules that must be adhered to. No specific message usage guidelines have been defined.
Business examples
For an example of how the MT n95 and n96 can be used, see the SWIFT User Handbook.
2.2.4
MT 999 Free Format Message

This message type is normally used by financial institutions to send information for which another message type is not applicable.
Scope
17 December 2008
29
Usage
It must only be used for scenarios pre-agreed between a corporate and its financial institution.

The SWIFT User Handbook, Volume Standards Category n, Common Group Messages, n99 Free Format Message contains the field specifications for this message. No specific message usage guidelines have been defined.
2.3
Account Reporting
The SWIFT User Handbook, Volume Standards Category 9, Cash Management and Customer Status serves as the main document describing the standards. The following text only serves to advise on which message must be used for which purpose. In order to facilitate the use of some of the MTs, some additional usage rules have been defined. The following topics describe Category 9 messages that are most relevant in the context of corporate payments and cash management. At the end of this section, you will also find a description of the MT 210 Notice to Receive (cat.2 message) which can be sent by an account owner to one of its account servicing institutions to pre-advise expected incoming funds on the account owners account.
2.3.1
MT 900 Confirmation of Debit

This message type is sent by an account servicing institution to an account owner (or a party authorised by the account owner to receive the information). It is used to notify the account owner of an entry which has been debited to its account. The entry will be further confirmed by statement.
Scope
Usage
This message type is not normally sent if statements for the account are frequently transmitted. This message type does not normally result in any bookings. It is a confirmation to the receiver (account owner or party authorised by the account owner to receive the information) of a debit to its account.

The SWIFT User Handbook, Volume Standards Category 9, MT 900 Confirmation of Debit contains full field specifications and network validated rules that must be adhered to. No specific message usage guidelines have been defined. In order to facilitate the use of the MT 900 for customer-to-bank usage, an additional usage guideline has been defined. A guideline is a recommendation, a best practice that must be followed whenever possible.
Field 72 Sender to Receiver Information
30
UHB definition
This field contains additional information for the Receiver. Usage Rule: Codes to be used may be agreed to bilaterally.
Additional usage guideline [guideline applicable as from 21 November 2009]
When the clearing system through which the account servicing institution has sent or received the instruction needs to be reported, the following code may be used, placed between slashes ('/') and followed by the clearing system identification code and/or number. CLRSID Clearing system identification
Business Example
The example included here refers to business example 1A of the Payment Initiation section.
Narrative
PlantOil sent an MT 101 to its USD bank, AAAAUS33 requesting to make a number of payments from its account 12345-67891. Payment details:
On behalf of PlantOilAxim, for 118,982.05 USD to Wung Lu Manufacturing at BBBBCNBJ (account number 60648929889) in Beijing, CN. On behalf of PlantOilProductions, for 50,000 USD, to Tristan Recording Studios at CCCCGB2L (account 0010499) in London, GB. On behalf of PlantOil Company, for 377,250 USD, to River Paper Company at DDDDUS33 (account number 26351-38947) in San Francisco, CA.
PlantOil indicated in the MT 101 it would like to see 1 batched entry on its account for the different transactions. AAAAUS33 Bank debits the account of PlantOil and initiates a credit transfer (in its books or by forwarding an MT102/103 or local credit transfer message). AAAUS33 Bank can send an MT 900 to PlantOil to notify that the payment has been debited from its account. AAAAUS33 will confirm this entry in the MT 940 statement message.
Information flow
17 December 2008
31
SWIFT message
Explanation Header Sender Message Type Receiver Message text Transaction Reference Number Related Reference* Account Identification Value Date, Currency Code, Amount :20:C11126A1378 :21:PLTOL101-56 :25:1234567891 :32A:060929USD546232,05 AAAAUS33 900 PLATUS33 Format
Notes:
* = In field 21, related reference, AAAAUS33 quotes a relevant customer reference. In this scenario, AAAAUS33 quotes the customer specified reference PTOL101-56 of the MT 101. By using this field in the MT 101, PlantOil indicated it wanted a batch entry booking for the MT 101. In case PlantOil had requested individual entries for each of the transactions contained in the MT 101, and AAAAUS33 could have advised of the individual debits through several MT 900s, quoting in Related Reference field 21 of each of the transactions included in the MT 101.
2.3.2
MT 910 Confirmation of Credit

This message is sent by an account servicing institution to an account owner (or a party authorised by the account owner to receive the information). It is used to notify the account owner of an entry which has been credited to its account. The entry will be further confirmed by statement.
Scope
Usage
This message type is not normally sent if statements for the account are frequently transmitted. This message type does not normally result in any bookings. It is a confirmation to the receiver (account owner or party authorised by the account owner to receive the information) of a credit to its account.

The SWIFT User Handbook, Volume Standards Category 9, MT 910 Confirmation of Credit contains full field specifications and network validated rules that must be adhered to. No specific message usage guidelines have been defined.
Business Example
The example included here refers to business example 1A of the Payment Initiation section.
32
Narrative
PlantOil sent an MT 101 to its USD bank, AAAAUS33 requesting to make a number of payments from its account 12345-67891. Payments details:
On behalf of PlantOilAxim, for 118,982.05 USD to Wung Lu Manufacturing at BBBBCNBJ (account number 60648929889) in Beijing, CN. On behalf of PlantOilProductions, for 50,000 USD, to Tristan Recording Studios at CCCCGB2L (account 0010499) in London, GB. On behalf of PlantOil Company, for 377,250 USD, to River Paper Company at DDDDUS33 (account number 26351-38947) in San Francisco, CA.
AAAAUS33 debited the account of PlantOil and initiated several credit transfers. For the second payment transaction included in the MT 101, AAAAUS33 services a USD account for CCCCGB2L (the beneficiary customers bank), credits this account and sends an MT 103 Customer Transfer to CCCCGB2L to instruct the payment to Tristan Recording Studios. CCCCGB2L services both a GBP and USD account for Tristan Recording Studios. Upon receipt of the funds for its customer, CCCCGB2L can send an MT 910 to Tristan Recording Studios (TRSTGB2L) to inform its customer of the incoming credit. AAAAUS33 will confirm this entry in an MT 940 statement message.
Information flow
SWIFT message
Explanation Header Sender Message Type Receiver CCCCGB2L 910 TRSTGB2L Format
17 December 2008
33
Message text Transaction Reference Number Related Reference* Account Identification Value Date, Currency Code, Amount Ordering Customer** :20:C11126C9224 :21:12345 :25:0010499 :32A:060929USD50000, :50A:PLATUS33
Notes:
* = CCCCGB2L copies the reference of the interbank credit transfer message in the MT 910. ** = CCCCGB2L can include the ordering customer of the payment in the MT 910.
2.3.3
MT 940 Customer Statement Message

This message is used to transmit detailed information about all entries booked to an account, serviced by a financial institution.
Scope
Usage
In the bank-to-bank part of the payment chain, the MT 940 is normally sent by an account servicing institution (reporting institution) to a financial institution (forwarding institution) which has been authorised by the account owner to receive it. In the bank-to-corporate environment, this relay scenario is also supported by the MT 940: the forwarding institution forwards the MT 940 to the corporate (the account owner, or the party authorised by the account owner to receive the information). In a bank-to-corporate environment, however, the MT 940 is also to be used instead of the MT 950 directly between the account servicing financial institution and the corporate (the account owner, or the party authorised by the account owner to receive the information).
34
As the MT 950 Statement message does not allow to transport the additional information that typically needs to be reported on the entries of customer statements, the MT 940 is recommended to be used in all situations as statement message towards corporate customers.

The SWIFT User Handbook, Volume Standards Category 9, MT 940 Customer Statement contains full field specifications and network validated rules that must be adhered to. In order to facilitate the use of the MT 940 for bank-to-corporate usage, some additional usage guidelines have been defined. A rule must be adhered to, whereas a guideline is a recommendation, a best practice that must be followed whenever possible.
Field 86 Information to Account Owner (repetitive occurrence: occurrence after each occurrence of field 61 Statement line) > How to structure customer information UHB definition This field contains additional information on the transaction detailed in the preceding statement line and which is to be passed on to the account owner. Usage rules: This field may contain ERI to transport dual currencies, as explained in the chapter 'Euro - Impact on Category 9 Message Standards'. Since the charges field in the customer transfers is repetitive, it may be necessary to report more than one charges amount in the resulting statement. In this case, it is allowed to repeat the code word CHGS before the code word OCMT. The order in which the charges are specified is the same as in the customer transfers (the order in which the charges have been taken during the transaction). So, the last appearance of the code word CHGS always specifies the charges (if any) of the account servicing institution. In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash. The code may be repeated if the account servicing institution wants to report an exchange rate that it applied, in addition to the exchange rate received in the instruction. The order in which the exchange rates are specified is the same as the order in which the rates have been applied during the transaction. So, the last appearance of the code word EXCH always specifies the rate applied by the account servicing institution. An ordering party is identified with the preceding code /ORDP/. The information following this code is copied from field 50a of the customer payment order, or field 52a (sender if field 52a is not present) of the financial institution transfer. The code must be used at the beginning of a line. In case of a debit item, a beneficiary party may be identified with the preceding code /BENM/. The information following this code is copied from field 59a of the customer payment order, or field 58a of the financial institution transfer. The code must be used at the beginning of a line. In case remittance information from field 70 of the payment instruction is to be included in this field, it must be preceded by the code /REMI/. In case the information in field 72 of the payment instruction is intended for the account owner, it must be copied into field 86 as it is. Codes used in field 72 of the payment instruction have therefore the same meaning in field 86 of the statement. If only free text is used in field 72, it is to be copied as it is since a code in field 86 will not add any value. Additional usage rule Any structure that will be used between account servicing institution and account owner (in addition to the structure defined in the UHB) must be bilaterally agreed
17 December 2008
35
between these two parties. Field 86 Information to Account Owner (single occurrence, last field of the MT 940) -> How to identify the original sender of MT 940 in a relay scenario UHB definition Additional usage rule This field contains additional information on the transaction detailed in the preceding statement line and which is to be passed on to the account owner. In case of a relay scenario, it is recommended that the Forwarding bank includes the BIC of the original sender of the MT 940 in field 86, if space is available in field 86. This information must be included on the last line of field 86, preceded by the code /ORSD/. Note: If several messages (identified by the Sequence number in field 28Cof MT 940) must be sent for one statement, the information must be added to the last field 86 of the first statement message.
Business Examples
1A Direct scenario: narrative
AAAAUS33 services an account (1234567891) for its customer PlantOil (PLATUS33). On a daily basis, AAAAUS33 sends a MT 940 customer statement to its customer PlantOil (PLATUS33). On 29 September, AAAAUS33 has booked following transactions to the account:
Value date: 29 September 2006 Transaction type: SWIFT transfer MT 101 Customer Reference of the MT 101: PLTOL101-56 Reference of AAAAUS33: C11126A1378 Details: Ordering customer = PLATUS33 Batch booking requested. Total amount of transactions = USD 546232,05. Note: this MT 101 is illustrated in business example 1A of the Payment Initiation section. Value date: 29 September 2006 Transaction type: SWIFT transfer MT 103 Reference of the MT 103: 987009 Reference of AAAAUS33: 8951234 Details: Ordering customer = Computersys Inc. Information for the Account Owner (field 70 of the MT 103): /INV/78541 Value date: 29 September 2006 Transaction type: Settlement of F/X Contract Reference for the Account Owner: AAAAUS0369PLATUS Reference of AAAAUS33: 8954321 Value Date: 29 September 2006 Transaction Type: Dividend Reference for the Account Owner: None Reference of AAAAUS33: 8846543 Information for the Account Owner: Dividend Loral Corp Preferred stock 1st quarter 2006 Debit: USD 100000 Credit: USD 500000 Debit: USD 546232,05
Credit: USD 200000
Information flow
36
SWIFT message
Explanation Header Sender Message Type Receiver Message text Transaction Reference Number Account Identification Statement Number/Sequence Number Opening Balance 1st Transaction* 2nd Transaction Info to Acct Owner** 3rd Transaction 4th Transaction Information to Account Owner Closing Book Balance :20:123456 :25: 1234567891 :28C:123/1 :60F:C060928USD28000,00 :61:060929D546232,05S101 PLTOL10156//C11126A1378 :61:060929C500000,S103987009//8951234 :86:/ORDP/COMPUTERSYS INC. /REMI//INV/78541 :61:060929D100000,NFEX AAAAUS0369PLATUS //8954321 :61:060929C200000,NDIVNONREF//8846543 :86:DIVIDEND LORAL CORP PREFERRED STOCK 1ST QUARTER 2006 :62F:C060629USD81767,95 AAAAUS33 940 PLATUS33 Format
Notes:
= This entry relates to the MT 101 transaction initiated by PLATUS33. In the MT 101, PlantOil indicated it wanted a batch entry booking for the MT 101, by completing field 21R Customer Reference (with reference PTOL101-56). ** = As described in the UHB, codes are available to structure field 86 Information for the Account Owner. Some of these codes are illustrated here. /ORDP/ identifies the ordering customer that ordered the payment, whereas the information after the code /REMI/ has been copied from the interbank customer credit transfer (for example, field 70 of an MT 103 Customer Credit Transfer). Please note that, if structured, the structure of field 86 must be agreed between account servicer and account owner (as described in the Message Usage Guidelines section of the MT 940).
1B. Relay scenario: narrative

The example illustrated above (under 1A) can also be used in a relay scenario (provided such a scenario has been agreed between all relevant parties). In this case, PlantOil has agreed with AAAAUS33 to receive all its account information (also from its other accounts held at other account servicing institutions) through AAAAUS33. The other account servicing institutions send the MT 940 for PlantOil to AAAAUS33. When forwarding the MT 940 to PlantOil (PLATUS33), AAAAUS33 will include the BIC of the original sender of the MT 940 in the single occurrence of field 86 Information to Account Owner, preceded by the code /ORSD/ - as described in the Message Usage Guidelines of the MT 940.
17 December 2008
37
2.3.4
MT 941 Balance Report

This message is used to transmit balance information, reflecting the situation at the identified time in field 13D.
Scope
Usage
In the bank-to-bank part of the payment chain, the MT 941 is normally sent by an account servicing institution (reporting institution) to a financial institution (forwarding institution) which has been authorised by the account owner to receive it. In the bank-to-corporate environment, this relay scenario is also supported by the MT 941: the forwarding institution forwards the MT 940 to the corporate (the account owner, or the party authorised by the account owner to receive the information). In a bank-to-corporate environment, however, the MT 941 can also be used directly between the account servicing financial institution and the corporate (the account owner, or the party authorised by the account owner to receive the information).

The SWIFT User Handbook, Volume Standards Category 9, MT 941 Balance Report contains full field specifications and network validated rules that must be adhered to.
38
No specific message usage guidelines have been defined.
Business example
For an example of how the MT 941 can be used, see the SWIFT User Handbook.
2.3.5
MT 942 Interim Transaction Report

This message is used to transmit detailed and/or summary information about entries debited or credited to the account since the last statement or balance report, or the last interim transaction report (sent in the period since the last statement or balance report).
Scope
Usage
In the bank-to-bank part of the payment chain, the MT 942 is normally sent by an account servicing institution (reporting institution) to a financial institution (forwarding institution) which has been authorised by the account owner to receive it. In the bank-to-corporate environment, this relay scenario is also supported by the MT 942: the forwarding institution forwards the MT 942 to the corporate (the account owner, or the party authorised by the account owner to receive the information). In a bank-to-corporate environment however, the MT 942 is also to be used directly between the account servicing financial institution and the corporate (the account owner, or the party authorised by the account owner to receive the information).
Depending on financial practice and the agreement(s) between the account servicing institution and the account owner, the items reported in this message may or may not be considered as booked or available funds.

The SWIFT User Handbook, Volume Standards Category 9, MT 942 Customer Statement contains full field specifications and network validated rules that must be adhered to. In order to facilitate the use of the MT 942 for bank-to-customer usage, some additional usage guidelines have been defined. In addition to the usage guideline defined below, the usage
17 December 2008
39
guidelines are exactly the same as for the MT 940, (refer to the relevant Message Usage Guidelines section of the MT 940 earlier in this document). A guideline is a recommendation, a best practice that must be followed whenever possible.
Field 86 Information to Account Owner UHB definition This field contains additional information for the Receiver. Usage Rule: Codes to be used may be agreed to bilaterally. Additional usage guideline [guideline applicable as from 21 November 2009] When the clearing system through which the account servicing institution has sent or received the instruction needs to be reported, the following code may be used, placed between slashes ('/') and followed by the clearing system identification code and/or number. CLRSID Clearing system identification
Business example
AAAAUS33 services two accounts (12345 and 67890) for its customer BioGenUs. BioGen US uses its shared service center BIOGNL2A to make all its payments, and to receive its account information. All parties involved have agreed to exchange daily one interim transaction report (MT 942), followed by an end-of-day customer statement (MT 940) for each of the accounts. On 29 September, at 2 PM, AAAAUS33 has posted following transactions to Bio Gens account 12345:
Value date: 29 September 2006 Transaction type: SWIFT transfer MT 101 Transaction Reference (transaction 1) of the MT 101: TR1-BIOG Reference of AAAAUS33: A8907 Details: Beneficiary customer = El Puerto Productions Note: This MT 101 is illustrated in business example 3A of the Payment Initiation section. Value date: 29 September 2006Transaction type: Direct Debit Reference for the account owner: DD98765 Reference of AAAAUS33: A8908 Details: Debtor = TELEBOR INC Value date: 29 September 2006 Transaction type: Domestic Transfer Reference for the Account Owner: None Reference of AAAAUS33: A8909 Details: Ordering Customer: Bottle and Co Remittance information: /INV/YUI56//YUI57 Expected Credit: USD 3000 Debit: USD 30000
Credit: USD 100000
As per agreement, AAAAUS33 will send an MT 942 message to BIOGNL2A to report these transactions.
40
Information flow
SWIFT message
Explanation Header Sender Message Type Receiver Message text Transaction Reference Number Account Identification Statement Number/Sequence Number Date/Time Indication 1st Transaction* Information to Account Owner** 2nd Transaction Info to Account Owner 3rd Transaction Info to Account Owner** Number and Sum of Debits Number and Sum of Credits :20:8765 :25:12345 :28C:218/1 AAAAUS33 942 BIOGNL2A Format
:13D:0609290200-0500
:61:060929D30000,S101TR1-BIOG// A8907 :86:/BENM/EL PUERTO PRODUCTIONS :61:060929EC3000,NDDTDD98765//A8908 :86:/ORDP/TELEBOR INC :61:060929C100000,NTRF NONREF//A8909 :86:/ORDP/BOTTLES AND CO /REMI//INV/YUI56//YUI57
:90D:1USD30000, :90C:2USD103000,
Notes:
* = This entry relates to one of the transactions included in the MT 101 initiated by BIOGNL2A. The appropriate reference of the transaction in the MT 101 is copied into the subfield Reference for the Account Owner. ** = As described in the UHB, codes are available to structure field 86 Information for the Account Owner. Some of these codes are illustrated here. /ORDP/ identifies the ordering customer/debtor, whereas the information after the code /REMI/ has been copied from the interbank customer credit transfer (e.g. field 70 of an MT 103 Customer Credit Transfer, or a remittance field of a domestic transfer). Please note that, if structured, the structure of field 86 must be agreed between account servicing institution and account owner (as described in the Message Usage Guidelines section of the MT 940).
17 December 2008
41
2.3.6
MT 210 Notice to Receive

This message type is sent by an account owner (or a party authorised by the account owner) to one of its account servicing institutions. It is an advance notice to the account servicing institution that it will receive funds to be credited to the sender's account.
Scope
Usage
This message will typically be used to ensure the account servicing institution is informed in advance of incoming funds in favour of the account owner. This message will allow the account servicing institution to have an early visibility of the incoming funds; it will help manage its liquidity and ensure the account owner get credited with good value date.

The SWIFT User Handbook, Volume Standards Category 2, MT 210 Notice to Receive contains full field specifications and network validated rules that must be adhered to.
Additional usage guidelines

Field 25 account identification (optional field) UHB definition Additional usage rule This field identifies the account to be credited with the incoming funds In order to clearly identify the account that will be credited, the account servicing institution may require this field to be included.
Business example Narrative

On September 21, 2006 BIG CARS Company in Frankfurt agrees on a Foreign Exchange trade with Bank A in London. BIG CARS buys 675,100 GBP and sells 1,000,000 EUR. The EUR will be settled from the account of BIG CARS with Bank B in Frankfurt to the account of Bank A also held with Bank B in Frankfurt . The GBP will be credited to the account of BIG CARS with Bank C in London. The value date is September 25, 2006. BIG CARS Company in Frankfurt will send an MT 210 to Bank C in London to inform it about the incoming GBP payment to be credited to its account 0010499.
42
Information flow
SWIFT message
Explanation Header Sender Message Type Receiver Message text Transaction Reference Number Account Identification Value Date Related Reference* Currency Code, Amount Ordering Institution :20:4587E254 :25: 0010499 :30:060925 :21: BANA2L6751BIGCFF :32B: GBP675100, :52A:BANAGB2L BIGCDEFF 210 BNKCGB2L Format
Note: *= reference of the underlying EUR/GBP forex deal
17 December 2008
43
3
3.1
Treasury Markets Standards

MT 300 Foreign Exchange Confirmation
Scope
This message is exchanged by or on behalf of the institutions or corporates, which have agreed to a foreign exchange contract. It is used to:
confirm the details of a new contract between the parties confirm an exercised foreign currency option confirm the details of an amendment to a previously sent confirmation cancel a previously sent confirmation
Usage rules
For the actual transfer of funds, other messages outside Category 3 are available, such as the MT 101, Request for Transfer message. When the sender of the MT 300 is confirming a trade on behalf of another party, this other party must be indicated in field 82a of the message, otherwise, the identification of the sender itself must appear in field 82. This message can also be used to confirm a currency swap. In that case, two confirmations must be sent: a spot one and a forward one. Non Deliverable Forward Trades may be confirmed by adding the NDF specific data in field 77D. The opening of a Non Deliverable Forward Trade contains the original amounts and two elements specific to this type of trade, the valuation date and the settlement currency. For the closing of the trade, the message has to contain opposite conditions, for example a full amount bought and a full amount sold. The net amount to be settled is calculated by netting the opening and the closing amounts. Note These guidelines are also applicable for non -deliverable trades settled via CLS.

Field 82a:Party A UHB definition This field identifies party A. Additional guideline This field must contain the party which will receive the amount bought and which will pay the amount sold. This field must contain the party which will pay the amount bought and which will receive the amount sold. For Non Deliverable Forward Opening confirmations, this field must contain on the first line /VALD/ followed by the valuation date in format YYYYMMDD and on the
87a: Party B
This field identifies party B.
77D: Terms and Conditions
This field specifies the underlying legal agreement.
44
Field
UHB definition
Additional guideline second line /SETC/ followed by the settlement currency in format XXX. For Non Deliverable Forward Valuation confirmations, this field must contain /FIX/ followed by the content of field 20 of the opening message.
Business example
On September 21, 2006 BIG CARS Company in Frankfurt agrees on a Foreign Exchange trade with Bank A in London. BIG CARS buys 1,000,000 GBP and sells 675,100 EUR. The EUR will be settled from the account of BIG CARS with Bank B in Germany to the account of Bank A with Bank B. The GBP will be credited to the account of BIG CARS with Bank C in London. The value date is September 25, 2006.
Explanation Sender Message Type Receiver Message text General Information Senders Reference Type of Operation Common Reference
Format BIGCDEFF 300 BANAGB2L
:15A: :20:123 :22A:NEWT :22C:BANA2L6751BIGCFF
17 December 2008
45
Party A Party B Transaction Details Trade Date Value Date Exchange Rate Currency, Amount Bought Receiving Agent Currency, Amount Sold Receiving Agent
:82A:BIGCDEFF :87A:BANAGB2L :15B: :30T:20060921 :30V:20060925 :36:0,6751 :32B:GBP1000000, :57A:BANCGB2L :33B:EUR675100, :57A:BANBDEFF
Business example
On November 22, 2006 BIG CARS Company in Frankfurt agrees on a Non Deliverable Forward trade with Bank A in London. BIG CARS buys 27,181,000 USD and sells 1,000,000,000 THB at value date January 22, 2007. The correspondent in USD of BIG CARS is Bank D in New York, while Bank A uses its branch in New York for USD settlement. The fixing date for the Non Deliverable trade is January 19, 2007.
Explanation Sender Message Type Receiver Message text General Information Senders Reference Type of Operation Common Reference Party A Party B Transaction Details Trade Date Value Date Exchange Rate Currency, Amount Bought Receiving Agent Currency, Amount Sold Receiving Agent Terms and Conditions :15A: :20:456 :22A:NEWT :22C:BANA2L7181BIGCFF :82A:BIGCDEFF :87A:BANAGB2L :15B: :30T:20061122 :30V:20070122 :36:0,27181 :32B:USD27181000, :57D:NET :33B:THB1000000000, :57D:NET :77D:/VALD/20070122 /SETC/USD Format BIGCDEFF 300 BANAGB2L
Business example
On January 19, 2007 BIG CARS Company in Frankfurt agrees on the settlement of a Non Deliverable Forward trade with Bank A in London. The new rate is 0.28235.
46
Explanation Sender Message Type Receiver Message text General Information Senders Reference Type of Operation Common Reference Party A Party B Transaction Details Trade Date Value Date Exchange Rate Currency, Amount Bought Receiving Agent Currency, Amount Sold Delivery Agent Receiving Agent Terms and Conditions
Format BIGCDEFF 300 BANAGB2L
:15A: :20:789 :22A:NEWT :22C:BANA2L8235BIGCFF :82A:BIGCDEFF :87A:BANAGB2L :15B: :30T:20070119 :30V:20070122 :36:0,28235 :32B:THB1000000000, :57D:NET :33B:USD28235000, :53A:BANDUS33 :57A:BANAUS33 :77D:/FIX/123
3.2
MT 320 Fixed Loan/Deposit Confirmation

Scope
This message is exchanged to confirm a fixed term loan/deposit contract. It is exchanged by or on behalf of the institutions or corporates, who have agreed to a fixed term loan/deposit contract. Note In some markets, loan/deposit contracts are agreed on floating rates.
The MT320 is not formatted to confirm floating rate contracts but bi-lateral agreements between parties are possible (see Message Guidelines and example).
Usage rules
For the actual transfer of funds, other messages outside Category 3 are available, such as the MT 101, Request for Transfer message. When the sender of the MT 320 is confirming a trade on behalf of another party, this other party must be indicated in field 82a of the message, otherwise, the identification of the sender itself must appear in field 82.
17 December 2008
47
Message usage guidelines Field 82a:Party A UHB definition This field identifies party A. Additional guideline In case of a loan, this field must contain the party which will receive the principal on the start date of the loan period. In case of a deposit, this field must contain the party which will transfer the principal on the start date of the deposit period. In case of a loan, this field must contain the party which will transfer the principal on the start date of the loan period. In case of a deposit, this field must contain the party which will receive the principal on the start date of the deposit period. For a floating rate loan/deposit, this field must contain /FLTR/ followed by the floating rate option in the confirmation sent at the start of the trade (field 22B contains CONF). In case of a new event (trade confirmation, rollover or maturity), this field must contain the code NEWT. In case of a correction or a modification of an event, this field must contain the code AMND. In case of the cancellation of an event, this field must contain the code CANC. This field must contain a negative sign when the amount is received from Party As point of view. Normally, the interest is included in this amount when and only when it is netted with the difference (ROLL) or reimbursement (MATU) of principal. For a floating rate loan/deposit, this field must contain an interest amount of zero in the confirmation sent at the start of the trade (field 22B contains CONF), while it must contain the actual total interest amount in the confirmation sent at maturity (field 22B contains MATU).
87a: Party B
This field identifies party B.
77D: Terms and Conditions
This field specifies the underlying legal agreement.
22A: Type of Operation
This field specifies the function of the message.
32H: Amount to be Settled
For a rollover confirmation (22B=ROLL), this field specifies the difference between the previous and the new principal amount, with interest included when interest is settled through the same cash flow. For a maturity confirmation (22B=MATU), this field specifies the amount with optional interest to be paid by the borrower at maturity date.
34x: Currency and Interest Amount
This field specifies for a new confirmation (22B=CONF), the first interest amount; a rollover confirmation (22B=ROLL), the next interest amount; a maturity confirmation (22B=MATU), the final interest amount to be settled at maturity.
48
37G: Interest Rate
This field specifies the interest rate.
For a floating rate loan/deposit, this field must contain an interest rate of zero in the confirmation sent at the start of the trade (field 22B contains CONF), while it must contain the actual rate in the confirmation sent at maturity (field 22B contains MATU).
Business example
On September 21, 2006 SPORTS CARS agrees to lend for 1 month starting September 25, 12,000,000 CHF to Savings Bank in Geneva. They will transfer the funds from their account with AnyBank in Geneva. The interest rate is 1.5495. BIG CARS Company in Frankfurt is responsible for confirming the trades of SPORTS CARS.
Explanation Sender Message Type Receiver Message text General Information Senders Reference Type of Operation Type of Event Common Reference Party A Party B
Format BIGCDEFF 320 SAVECHFF
:15A: :20:ABC :22A:NEWT :22B:CONF :22C:BIGCFF5495SAVEGG :82A:SPOCDEF1 :87A:SAVECHGG
17 December 2008
49
Transaction Details Party As Role Trade Date Value Date Maturity Date Currency and Principal Amount Currency and Interest Amount Interest Rate Day Count Fraction Settlement Instructions for Amounts Payable by Party A. Intermediary Receiving Agent Settlement Instructions for Amounts Payable by Party B. Receiving Agent
:15B: :17R:L :30T:20060921 :30V:20060925 :30P:20061025 :32B:CHF12000000, :34E:NCHF15495, :37G:1,5495 :14D:360/360 :15C: :56A:ANYBCHGG :57A:SAVECHGG :15D: :57A:ANYBCHGG
Business example
On November 23, 2006 BIG CARS agrees to lend for 3 months starting November 27, 15,000,000 CHF to Savings Bank in Geneva. They will transfer the funds from their account with AnyBank in Geneva. The interest rate is CHF-ANNUALSR-RFRCBANKS.
Explanation Sender Message Type Receiver Message text General Information Senders Reference Type of Operation Type of Event Common Reference Party A
Format BIGCDEFF 320 SAVECHFF
:15A: :20:DEF :22A:NEWT :22B:CONF :22C:BIGCFF0000SAVEGG :82A:BIGCDEFF
50
Party B Terms and Conditions Transaction Details Party As Role Trade Date Value Date Maturity Date Currency and Principal Amount Currency and Interest Amount Interest Rate Day Count Fraction Settlement Instructions for Amounts Payable by Party A. Intermediary Receiving Agent Settlement Instructions for Amounts Payable by Party B. Receiving Agent
:87A:SAVECHGG :77D:/FLTR/CHF-ANNUALSR-RFRCBANKS :15B: :17R:L :30T:20061123 :30V:20061127 :30P:20070227 :32B:CHF15000000, :34E:CHF0, :37G:0, :14D:360/360 :15C: :56A:ANYBCHGG :57A:SAVECHGG :15D: :57A:ANYBCHGG
Business example
At maturity of the loan/deposit, 2006 BIG CARS confirms the floating rate which is of 2.75%.they repeat the floating rate option in field 77D.
Explanation Sender Message Type Receiver Message text General Information Senders Reference Related Reference Type of Operation Type of Event Common Reference Party A Party B Terms and Conditions Transaction Details Party As Role Trade Date Value Date Maturity Date Currency and Principal Amount :15A: :20GHI :21:DEF :22A:NEWT :22B:MATU :22C:BIGCFF0275SAVEGG :82A:BIGCDEFF :87A:SAVECHGG :77D:/FLTR/CHF-ANNUALSR-RFRCBANKS :15B: :17R:L :30T:20061123 :30V:20061127 :30P:20070227 :32B:CHF15000000, Format BIGCDEFF 320 SAVECHFF
17 December 2008
51
Currency and Amount to be Settled Currency and Interest Amount Interest Rate Day Count Fraction Settlement Instructions for Amounts Payable by Party A. Intermediary Receiving Agent Settlement Instructions for Amounts Payable by Party B. Receiving Agent
:32H:NCHF15103125, :34E:NCHF103125, :37G:2,75 :14D:360/360 :15C: :56A:ANYBCHGG :57A:SAVECHGG :15D: :57A:ANYBCHGG
3.3
MT 305 Foreign Currency Option Confirmation

Scope
This message is exchanged by or on behalf of the institutions or corporates, which have agreed to a foreign currency option contract. It is used to:
confirm the details of a new contract between the parties confirm the details of an amendment to a previously sent confirmation cancel a previously sent confirmation
Usage rules
For the actual transfer of the premium, other messages outside Category 3 are available, such as the MT 101, Request for Transfer message. The underlying master agreement is by default ICOM but variations of ICOM, or ISDA master agreements may also be specified. This message must be used to confirm Vanilla, Deliverable currency options with American or European exercise. Barriers cannot be specified. Please note the meaning of the combination of codes in field 23:
Field 23: Further Identification Code1 Buy Buy Sell Sell Code 2 Call Put Call Put Code 3 A or E A or E A or E A or E Currency = Field 32B Ccy Ccy Ccy Ccy Sender Sender Receiver Receiver Sender Receiver Receiver Sender Option Buyer Currency Buyer
52

Field 23:Further Identification UHB definition This field specifies whether, from the sender's point of view, the option is sold or bought, is a put or call, and indicates the style and the underlying currency. Additional guideline This field is composed of 3 codes and a currency. The currency code must be the same as the currency indicated in field 32B. The first code specifies whether the option is bought or sold, the second code specifies whether the option is a Put or a Call. For matching reasons, it is recommended to use for the location subfield, the same format as specified for field 29H of MT 306, that is the first 2 characters represent the ISO country code, the next two characters represent 1) if the location name is one word, the first two letters of the location 2) if the location name consists of at least two words, the first letter of the first word followed by the first letter of the second word. This field contains the currency exchanged against the underlying currency of the option (as indicated in field 32B).
31G:Expiry Details
This field specifies the date, time and location at which the option expires.
33B:Counter Currency and Amount
This field specifies the counter currency and amount. The counter currency is the currency which is to be exchanged for the underlying currency.
Business example
On November 23, 2006 BIG CARS Company in Frankfurt agrees on a Foreign Currency Option Contract with Bank A in London. BIG CARS buys an American option in EUR against USD for an amount of 10,000,000 EUR at a strike price of 1,5432. The option expires on February, 27th 2007 at 10:00 a.m. German time. The premium is 5% of the amount in EUR.
Explanation Sender Message Type Receiver Message text Transaction Reference Number Related Reference Common Reference Further Identification Date Contract Agreed Earliest Exercise Date Expiry Details Settlement Type :20:00A :21:00A :22:NEW/BANA2L5432BIGCFF :23:BUY/CALL/EUR/A :30:20061123 :31C:20061124 :31G:20070227/1000/DEFR :26F:PRINCIPAL Format BIGCDEFF 300 BANAGB2L
17 December 2008
53
Underlying Currency and Amount Strike Price Counter Currency and Amount Premium Price Premium Amount Account With Institution Terms and Conditions
:32B:EUR10000000, :36:1,5432 :33B:USD15432000, :37K:PCT5, :34P:EUR500000, :57A:BANADEFF :77D:/ISDA/20030712
54
Securities Standards
SWIFT offers a range of ISO 15022 standards (MTs) to instruct and confirm the settlement of securities trades. A related set of standards is available for corporate action announcement, status, instructions, and confirmations. There are also ISO 15022 standards for the reporting of pending transactions, settled transactions and holdings. These statements are exchanged between an account servicer and an account owner for reconciliation purposes. The below section explains the above related MTs, and provides a series of guidelines facilitating the common usage of those message types. A set of business examples is provided at the end of this section.
For the usage of ISO 15022, SWIFT recommends compliance with market practice rules published by the Securities Market Practice Group (SMPG). These rules applies also to corporate to bank and bank-to-corporate communication. The following section describes basic usage of the messages. Detailed usage guidelines are available in the Securities Markets Message Usage Guidelines published in the User Handbook Online at www.swift.com > Ordering & Support > Documentation. You can find all market practice rules on www.smpg.info. It is advisable to discuss SMPG practices with your account servicer to ensure they abide by these guidelines.
17 December 2008
55
4.1
Settlement, Status and Allegement Messages

The SWIFT User Handbook, Volume Standards Category 5, Securities Markets as well as SMPG Settlement & Reconciliation Final Market Practices serve as the main documents describing the standards.
4.1.1
MT 540-3 Settlement Instructions
Scope
The MT 540-3 is sent by the corporate to the custodian bank. This message is used to:
instruct the receipt or delivery of financial instruments free or against payment, physically or by book-entry, from a specified party (the function of the message is NEWM) request the cancellation of a previously sent instruction by the account owner (the function of the message is CANC) pre-advise of a forthcoming receipt or delivery of financial instruments free or against payment instruction (the function of the message is PREA).
The instruction may be linked to other settlement instructions, for example, for a turnaround or back-to-back, or other transactions, for example, foreign exchange deal, using the linkages sequence. The MT 540 is used for Receive Free Instruction. The MT 541 is used for Receive Against Payment Instruction. The MT 542 is used for Deliver Free Instruction. The MT 543 is used for Deliver Against Payment Instruction.

The SWIFT User Handbook, Volume Standards Category 5, volume 2, MT 540-3 contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of settlement instructions, the SMPG publications are the following:
Equity and fixed income settlement global practice Securities lending and borrowing settlement
56
Block trades Book transfer ISO 15022 message function usage ISO 15022 linkages usage Status reporting Pair-off Partial settlement Physical settlement Place of safekeeping Place of settlement Pre-advice (hold/release process) Repurchase agreement settlement Sell-buy/buy-sell back settlement Settlement instruction linked FX Country specific requirements (25+ countries)
New or updated market practices are published on regular basis on www.smpg.info.
Business example
Note For all the following examples, the assumption is that appropriate agreements have been put in place between the different parties to act on the settlement instructions.
More examples are available in the Securities Markets Message Usage Guidelines in the UHB Online.
Narrative
Corporate ABCDUS33 purchased, on the 15th of December 2006, through Broker BROKUS33, face amount of 100000 USD of Commercial Papers US345397TT06 to expire 15th of March 2007. They instruct their Custodian Bank CUSTUS33 to receive the securities against payment of USD 103867 to be safe kept in their securities account 1234567891. Broker BROKUS33 informed Corporate ABCDUS33 that the securities will be delivered to custodian CUSTUS33 in DTCC by clearing broker CLEAUS33 on behalf of BROKUS33.
ISO 25022 message

Explanation Header Sender Message Type Receiver Message text ABCDUS33 541 CUSTUS33 Format
17 December 2008
57
Sequence A General Information Start of Block Senders Reference Function of the Message End of Block Sequence B Trade Details Start of Block Trade Date Settlement Date Deal Price Identification of the securities End of Block Sequence C Financial Instrument Account Start of Block Quantity to be received Safekeeping account End of Block Sequence E Settlement Details Start of Block Type of settlement transaction: regular trade Repetitive Sequence E1 Settlement Parties* Start of Block Seller End of Block Start of Block Delivering Agent** End of Block Start of Block Place of settlement End of Block Repetitive Sequence E3 Amounts Start of Block Settlement Amount End of Block Start of Block Deal Amount End of Block :16R:AMT :19A::SETT//USD103867, :16S:AMT :16R:AMT :19A::DEAL//USD103867, :16S:AMT :16R:SETPRTY :95P::SELL//BROKUS33 :16S:SETPRTY :16R:SETPRTY :95R::DEAG/DTCYID/03124569 :16S:SETPRTY :16R:SETPRTY :95P::PSET///DTCYUS33 :16S:SETPRTY :16R:SETDET :22F::SETR//TRAD :16R:FIAC :36B::SETT//FAMT/100000, :97A::SAFE//1234567891 :16S:FIAC :16R:TRADDET :98A::TRAD//20061215 :98A::SETT//20061218 :90B::DEAL//PRCT/103,867 :35B:ISIN US345397TT06 :16S:TRADDET :16R:GENL :20C::SEME//TRADECP001 :23G:NEWM :16S:GENL
58
End of Block
:16S:SETDET
Notes:
* Note that, depending on service level agreement, the settlement party information might be limited to providing the broker and a reference to a SSI database to be used by the custodian bank. The specifics about how and what instruct in that case is to be agreed with the custodian bank. ** As per US country market practice, the delivering agent, that is, the clearing broker in this example, must be identified using its DTCC code.
4.1.2
MT 548 Settlement Status and Processing Advice
Scope
The MT 548 is sent by the custodian bank to the corporate. This message is used to:
advise the status of a settlement instruction (the function of the message is INST) as a reply to a cancellation request previously sent by the corporate (the function of the message is CAST) report on future settlement, or forward transactions, for example, free receipts for which no instruction is required, which have become binding to the corporate

The SWIFT User Handbook, Volume Standards Category 5, volume 3, MT 548, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of Settlement Status and Processing Advice, the SMPG publications are the following:
ISO 15022 message function usage ISO 15022 linkages usage Status reporting (MT 548, 537)
17 December 2008
59
Business example
More examples are available in the Securities Markets Message Usage Guidelines in the UHB Online.
Narrative
On December 17th, Custodian Bank CUSTUS33 informs Corporate ABCDUS33 that their purchase of US345397TT06 is pending settlement.
ISO 15022 message

Explanation Header Sender Message Type Receiver Message text Sequence A General Information Start of Block Senders Reference Function of the Message Sequence A1 Linkages Start of Block Link to the instruction the MT 548 is about End of Block End of Block Sequence A2 Status Start of Block Settlement Status Sequence A2a Reason Start of Block Reason (Transaction is pending settlement) End of Block End of Block Sequence B Settlement Transaction Details Start of Block Identification of the securities Quantity to be received Settlement Amount Safekeeping account Type of settlement transaction: regular trade :16R:SETTRAN :35B:ISIN US345397TT06 :36B::SETT//FAMT/100000, :19A::SETT//USD103867, :97A::SAFE//1234567891 :22F::SETR//TRAD :16R:REAS :24B::PEND//FUTU :16S:REAS :16S:STAT :16R:STAT :25D::SETT//PEND :16R:LINK :20C::RELA//TRADECP001 :16S:LINK :16S:GENL :16R:GENL :20C::SEME//STATUS123456 :23G:INST CUSTUS33 548 ABCDUS33 Format
60
Receive/Deliver Indicator Payment Indicator Trade Date Settlement Date Repetitive Sequence B1 Settlement Parties Start of Block Seller End of Block Start of Block Delivering Agent* End of Block Start of Block Place of settlement End of Block End of Block
:22F::REDE//RECE :22F::PAYM//APMT :98A::TRAD//20061215 :98A::SETT//20061218
:16R:SETPRTY :95P::SELL//BROKUS33 :16S:SETPRTY :16R:SETPRTY :95R::DEAG/DTCYID/03124569 :16S:SETPRTY :16R:SETPRTY :95P::PSET///DTCYUS33 :16S:SETPRTY :16S: SETTRAN
Note:
* More settlement transaction details may be provided
4.1.3
MT 544-7 Settlement Confirmations
Scope
The MT 544-7 is sent by the custodian bank to the corporate. This message is used to:
confirm a delivery or receive of financial instruments against or free of payment (function of the message is NEWM) request the cancellation or reversal of a previously sent confirmation (function of the message is CANC or RVSL)
The MT 544 is used to confirm a Receive Free Instruction The MT 545 is used to confirm a Receive Against Payment Instruction The MT 546 is used to confirm a Deliver Free Instruction
17 December 2008
61
The MT 547 is used to confirm a Deliver Against Payment Instruction

The SWIFT User Handbook, Volume Standards Category 5, volume 3, MT 544-7, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of Settlement confirmations, the SMPG publications are as referred in section 4.1.1.
Business example
Please note that for all the following examples, the assumption is that appropriate agreements have been put in place between the different parties to act on the settlement instructions. More examples are available in the Securities Markets Message Usage Guidelines in the UHB Online.
Narrative
On December 18th, Custodian Bank CUSTUS33 confirms to Corporate ABCDUS33 that their purchase of US345397TT06 is settled.
ISO 15022 message

Explanation Header Sender Message Type Receiver Message text Sequence A General Information Start of Block Senders Reference Function of the Message Sequence A1 Linkages Start of Block Link to the instruction the MT 548 is about End of Block End of Block Sequence B - Trade Details Start of Block Trade Date Settlement Date :16R:TRADDET :98A::TRAD//20061215 :98A::ESET//20061218 :16R:LINK :20C::PREV//TRADECP001 :16S:LINK :16S:GENL :16R:GENL :20C::SEME//CONF1234 :23G:NEWM CUSTUS33 545 ABCDUS33 Format
62
Deal Price Identification of the securities End of Block Sequence C Financial Instrument Account Start of Block Quantity to be received Safekeeping account End of Block Sequence E Settlement Details Start of Block Type of settlement transaction: regular trade Repetitive Sequence E1 Settlement Parties Start of Block Seller End of Block Start of Block Delivering Agent End of Block Start of Block Place of settlement End of Block Repetitive Sequence E3 Amounts Start of Block Settlement Amount End of Block Start of Block Deal Amount End of Block End of Block
:90B::DEAL//PRCT/103,867 :35B:ISIN US345397TT06 :16S:TRADDET
:16R:FIAC :36B::ESTT//FAMT/100000, :97A::SAFE//1234567891 :16S:FIAC
:16R:SETDET :22F::SETR//TRAD
:16R:SETPRTY :95P::SELL//BROKUS33 :16S:SETPRTY :16R:SETPRTY :95R::DEAG/DTCYID/03124569 :16S:SETPRTY :16R:SETPRTY :95P::PSET///DTCYUS33 :16S:SETPRTY
:16R:AMT :19A::ESTT//USD103867, :16S:AMT :16R:AMT :19A::DEAL//USD103867, :16S:AMT :16S:SETDET
17 December 2008
63
4.1.4
MT 578 Settlement Allegement
Scope
advise the corporate that a counterparty has alleged a settlement instruction against the corporate account at the custodian, and that the custodian could not find the corresponding instruction (the function of the message is NEWM) request the cancellation or removal of a previously sent settlement allegement (the function of the message is CANC or REMO)

The SWIFT User Handbook, Volume Standards Category 5, volume 4, MT 578 contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of settlement allegement, the SMPG publications are the following:
ISO 15022 message function usage ISO 15022 linkages usage Settlement allegements (MT 578, 586)
Business example
See examples available in the Securities Markets Message Usage Guidelines in the UHB Online.
4.2
Reconciliation Messages
The SWIFT User Handbook, Volume Standards Category 5, Securities Markets as well as SMPG Settlement & Reconciliation Final Market Practices serves as the main documents describing the standards.
64
Reconciliation messages are sent by a custodian bank to a corporate. The choice of statement and the frequency is typically described in a service level agreement. It is however possible (when this service is offered) to request a statement using the MT 549 Request for Statement/Status Advice (for info on MT 549 formats, see the SWIFT User Handbook).
4.2.1
MT 537 Statement of Pending Transactions
Scope
provide the corporate with the details of pending transactions at a specified moment in time. The message may contain details for all, or a selected quantity of securities for a specified safekeeping account. It may also give all, or a selected number of reasons why the transaction is pending. The statement may also include future settlement, or forward, transactions which have become binding to the account owner. The statement may be sorted per status or per transaction. (the function of the message is NEWM) request the cancellation of a previously sent statement (the function of the message is CANC)

The SWIFT User Handbook, Volume Standards Category 5, volume 2, MT 537, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages.
17 December 2008
65
On the Statement of Pending Transactions, the SMPG publications are the following:
ISO 15022 message function usage ISO 15022 linkages usage Status reporting (MT 548, 537)
Business example
Please note that for all the examples illustrated below, the assumption is that appropriate agreements have been put in place between the different parties on the type of report and frequency of the statement that must be sent. More examples are available in the Securities Markets Message Usage Guidelines in the UHB Online.
Narrative
On a daily basis, Custodian Bank CUSTUS33 sends a statement of pending transactions to Corporate ABCDUS33 for its securities account 1234567891. This statement provides a status on all pending transactions for this account.
ISO 15022 message

Explanation Header Sender Message Type Receiver Message text Sequence A General Information Start of Block Page Number/ Continuation Indicator Statement Number Senders Reference Function of the Message Statement Date Statement Frequency Indicator (Daily) Complete/Update Indicator (Complete) Statement Structure Type Indicator Safekeeping Account Activity Flag End of Block Sequence B Status Start of Block :16R:STAT :16R:GENL :28E::00001/ONLY :13A::STAT//001 :20C::SEME//REPORT1 :23G:NEWM :98A::STAT//20061216 :22F::SFRE//DAIL :22F::CODE//COMP :22F::STST//STAT :97A::SAFE//1234567891 :17B::ACTI//Y :16S:GENL CUSTUS33 537 ABCDUS33 Format
66
Settlement Status Sequence B1- Reason Start of Block Reason (Transaction is pending settlement) End of Block Sequence B2 Transaction Start of Block Sequence B2a Linkages Start of Block Link to the instruction the MT 548 is about End of Block Sequence B2b Transaction Details Start of Block Identification of the securities Quantity to be received Settlement Amount Transaction Indicator: Settlement and Clearing Activity Type of settlement transaction: regular trade Receive/Deliver Indicator Payment Indicator Trade Date Settlement Date Repetitive Sequence B2b1 Settlement Parties Start of Block Seller End of Block Start of Block Delivering Agent* End of Block Start of Block Place of settlement End of Block End of Block End of Block End of Block **
:25D::SETT//PEND
:16R:REAS :24B::PEND//FUTU :16S:REAS
:16R:TRAN
:16R:LINK :20C::RELA//TRADECP001 :16S:LINK
:16R:TRANSDET :35B:ISIN US345397TT06 :36B::PSTA//FAMT/100000, :19A::PSTA//USD103867, :22F::TRAN//SETT :22F::SETR//TRAD :22F::REDE//RECE :22F::PAYM//APMT :98A::TRAD//20061215 :98A::SETT//20061218
:16R:SETPRTY :95P::SELL//BROKUS33 :16S:SETPRTY :16R:SETPRTY :95R::DEAG/DTCYID/03124569 :16S:SETPRTY :16R:SETPRTY :95P::PSET///DTCYUS33 :16S:SETPRTY :16S:TRANSDET :16S:TRAN :16S:STAT
17 December 2008
67
Notes:
* Other pending future (:25D::SETT//PEND,:24B::PEND//FUTU) transactions will follow here. ** Transactions with another status, etc.
4.2.2
MT 536 Statement Transactions
Scope
provide the details of any increases and/or decreases of holdings, which may have occurred over a specified period of time, for all, or a selected quantity of securities in the safekeeping account which the custodian bank holds for the corporate request the cancellation of a previously sent statement (the function of the message is CANC)

The SWIFT User Handbook, Volume Standards Category 5, volume 2, MT 536, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the Statement of Transactions, the SMPG publications are the following:
ISO 15022 message function usage ISO 15022 linkages usage Statement of Transaction (MT 536 MP)
Business example
For all the following examples, the assumption is that appropriate agreements have been put in place between the different parties on the type of report and frequency of the statement that must be sent. More examples are available in the Securities Markets Message Usage Guidelines in the UHB Online.
68
Narrative
On a daily basis, Custodian Bank CUSTUS33 sends a statement of transactions to Corporate ABCDUS33 for its securities account 1234567891. This statement provides increase and decrease of positions following the settlement of transactions for this account.
ISO 15022 message

Explanation Header Sender Message Type Receiver Message text Sequence A General Information Start of Block Page Number/ Continuation Indicator Statement Number Senders Reference Function of the Message Statement Period Statement Frequency Indicator (Daily) Complete/Update Indicator (Complete) Safekeeping Account Activity Flag Sub-safekeeping Statement End of Block Sequence B Subsafekeeping Account Start of Block Sequence B1- Financial Instrument Start of Block Identification of the securities Sequence B1a Transaction Start of Block Sequence B1a1 Linkages Start of Block Link to the instruction the MT 548 is about End of Block Sequence B1a2 Transaction Details Start of Block :16R:TRANSDET :16R:LINK :20C::RELA//TRADECP001 :16S:LINK :16R:TRAN :16R:FIN :35B:ISIN US345397TT06 :16R:SUBSAFE :16R:GENL :28E::00001/ONLY :13A::STAT//001 :20C::SEME//REPORT1 :23G:NEWM :69A::STAT//20061217/20061218 :22F::SFRE//DAIL :22F::CODE//COMP :97A::SAFE//1234567891 :17B::ACTI//Y :17B::CONS//N :16S:GENL CUSTUS33 536 ABCDUS33 Format
17 December 2008
69
Quantity to be received Settlement Amount Transaction Indicator: Settlement and Clearing Activity Type of settlement transaction: regular trade Receive/Deliver Indicator Payment Indicator Trade Date Settlement Date Repetitive Sequence B2b1 Settlement Parties Start of Block Seller End of Block Start of Block Delivering Agent* End of Block Start of Block Place of settlement End of Block End of Block End of Block * End of Block ** End of Block
:36B::PSTA//FAMT/100000, :19A::PSTA//USD103867, :22F::TRAN//SETT :22F::SETR//TRAD :22F::REDE//RECE :22F::PAYM//APMT :98A::TRAD//20061215 :98A::ESET//20061218
:16R:SETPRTY :95P::SELL//BROKUS33 :16S:SETPRTY :16R:SETPRTY :95R::DEAG/DTCYID/03124569 :16S:SETPRTY :16R:SETPRTY :95P::PSET///DTCYUS33 :16S:SETPRTY :16S:TRANSDET :16S:TRAN
:16S:FIN
:16S:SUBSAFE
Notes:
* Other settled transactions for ISIN US345397TT06 will follow here. ** Settled transactions for other ISINs will follow here.
4.2.3
MT 535 Statement of Holdings
70
Scope
report on the quantity and identification of financial instruments which the custodian bank holds for the corporate at a specified moment in time (the function of the message is NEWM) When the message is sent by a custodian to a customer, the statement must be clearly identified as either a custody, or an accounting statement. The custody statement reports on the availability and/or the location of security holdings, to facilitate trading and minimise settlement issues. The Accounting Statement provides valuations of the portfolio with details of each security holding, it is not used for trading purposes.
request the cancellation of a previously sent statement (the function of the message is CANC)

The SWIFT User Handbook, Volume Standards Category 5, volume 2, MT 535, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the Statement of Transactions, the SMPG publications are the following:
ISO 15022 message function usage ISO 15022 linkages usage Statement of Holdings (MT 535 MP)
Business example
For all the following examples, the assumption is that appropriate agreements have been put in place between the different parties on the type of report and frequency of the statement that must be sent. More examples are available in the Securities Markets Message Usage Guidelines in the UHB Online.
Narrative
On a daily basis, Custodian Bank CUSTUS33 sends a custody statement of holdings to Corporate ABCDUS33 for its securities account 1234567891. This statement provides holdings for this account.
ISO 15022 message

Explanation Header Sender CUSTUS33 Format
17 December 2008
71
Message Type Receiver Message text Sequence A General Information Start of Block Page Number/ Continuation Indicator Statement Number Senders Reference Function of the Message Statement Date Statement Frequency Indicator (Daily) Complete/Update Indicator (Complete) Statement Type (Custody) Statement Basis (Settled positions) Safekeeping Account Activity Flag Sub-safekeeping Statement End of Block Sequence B Subsafekeeping Account Start of Block Sequence B1- Financial Instrument Start of Block Identification of the securities Balance Balance available Balance not available End of Block * End of Block
535 ABCDUS33
:16R:GENL :28E::00001/ONLY :13A::STAT//001 :20C::SEME//REPORT1 :23G:NEWM :98A::STAT//20061218 :22F::SFRE//DAIL :22F::CODE//COMP :22F::STTY//CUST :22F::STBA//SETT :97A::SAFE//1234567891 :17B::ACTI//Y :17B::CONS//N :16S:GENL
:16R:SUBSAFE
:16R:FIN :35B:ISIN US345397TT06 :93B::AGGR//FAMT/100000, :93B::AVAI//FAMT/100000, :93B::NAVL//FAMT/0, :16R:FIN
:16S:SUBSAFE
Note:
* Other holdings will follow here.
72
4.2.4
MT 586 Statement of Settlement Allegements
Scope
provide the details of pending settlement allegements, for all or selected securities in a specified safekeeping account, for a given point in time (the function of the message is NEWM) request the cancellation of a previously sent statement of settlement allegements (the function of the message is CANC)

The SWIFT User Handbook, Volume Standards Category 5, volume 4, MT 586, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of settlement allegement, the SMPG publications are the following:
ISO 15022 message function usage ISO 15022 linkages usage Settlement allegements (MT 578, 586)
Business examples
See examples available in the Securities Markets Message Usage Guidelines in the UHB Online.
4.3
Asset Servicing Messages

The SWIFT User Handbook, Volume Standards Category 5, Securities Markets as well as SMPG Corporate Action Final Market Practices serve as the main documents describing the standards.
17 December 2008
73
4.3.1
Asset Servicing Messages Scope

MT 564
notify a corporate (account owner) with the details of a corporate action event occurring on an instrument that the corporate (account owner) holds (function of the message is NEWM) replace a previously sent notification with corrected or additional details (function of the message is REPL) inform about the entitlement details to the corporate (function of the message is REPE). According to the corporate action event type, the MT 564 entitlement calculation will specify the impact to the safekeeping account and/or the cash account based on: the number of underlying shares held by the corporate (account owner) the payment ratio and the terms of the offer (whether this is in the form of rights, shares, cash or options) the option selected by the corporate (account owner)
MT 565
remind of a corporate action for which the corporate (account owner) must instruct (the function of the message is RMDR) withdraw a notification for an event that will finally not take place (the function of the message is WITH) request the cancellation of a previously sent notification that was, for example, sent by mistake (the function of the message is CANC)
The MT 565 is sent by the corporate to the custodian bank. This message is used to:
provide the custodian with instructions on how the corporate (account owner) wishes to proceed with a voluntary or mandatory (with options) corporate action event. Instructions include investment decisions regarding the exercise of rights issues, the election of stock, or cash, when the option is available, and decisions on the conversion or tendering of securities (function of the message is NEWM) request the cancellation of a previously sent instruction that was, for example, sent by mistake (the function of the message is CANC)
74
MT 566
MT 567
confirm to the corporate that securities and/or cash have been credited/debited to an account, as the result of a corporate action event (function of the message is NEWM) reverse a previously sent confirmation (the function of the message is REVR)
advise the status, or a change in status, of a corporate-action-related transaction previously instructed by, or executed on behalf of, the corporate. This will include: the acknowledgment/rejection of a corporate action instruction (function of the message is INST) or the acknowledgment /rejection of a request to cancel an outstanding instruction (function of the message is CAST) it may also be used to provide the reason a corporate action event has not been completed by the announced payment dates (function of the message is EVST)
MT 568
The MT 568 is sent by the custodian bank to the corporate or from the corporate to the custodian. Sent by the custodian bank to the corporate, this message is used to provide narrative details relating to a corporate action event. Sent by the corporate to the custodian bank, this message is used to provide complex instructions.
4.3.2
Asset Servicing Messages Usage Guidelines and Examples

The SWIFT User Handbook, Volume Standards Category 5, volume 3, MT 564-7 and volume 4, MT 568, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the Statement of Pending Transactions, the SMPG publications are the following:
Event Interpretation Grid (EIG) CA Global Market Practice document CA Events Samples
17 December 2008
75
Business example
We will only give in this document one example of CA event for a commercial paper (redemption). Other event examples are available in the Securities Markets Message Usage Guidelines in the UHB Online but also in the SMPG CA event samples document. Note The details of the event may be different and other optional data may be provided in the message.
Narrative:
A commercial paper US345397TT06 will mature and be redeemed at par, or 100% of nominal face amount, on March 15th 2007. Corporate ABCDUS33 account 1234567891 holds at custodian bank CUSTUS33 a face amount of USD 100000. Custodian Bank CUSTUS33 sends a notification to corporate ABCDUS33 about the future redemption as ABCDUS33 holds this instrument and will be impacted by the CA event.
MT 564 Corporate Action Notification

Explanation Header Sender Message Type Receiver Message text Sequence A General Information Start of block Corporate action reference Senders reference Function of the message Final maturity Mandatory indicator Details are complete End of block Sequence B Underlying Securities Start of block Underlying securities :16R:USECU :35B:ISIN US345397TT06 Description of the instrument Sequence B2 Account Information Start of block Safekeeping account Eligible face amount balance End of block :16R:ACCTINFO :97A::SAFE//1234567891 :93B::ELIG//FAMT/100000, :16S:ACCTINFO :16R:GENL :20C::CORP//RDM3437592 :20C::SEME//1997189-012 :23G:NEWM :22F::CAEV//REDM :22F::CAMV//MAND :25D::PROC//COMP :16S:GENL CUSTUS33 564 ABCDUS33 Format
76
End of block Sequence D Corporate Action Details Start of block Redemption date End of block Sequence E Corporate Action Options Start of block CA option number Cash option Currency offered Default option Payment date Redemption price (100% par) End of block
:16S:USECU
:16R:CADETL :98A::REDM//20070315 :16S:CADETL
:16R:CAOPTN :13A::CAON//001 :22F::CAOP//CASH :11A::OPTN//USD :17B::DFLT//Y :98A::PAYD//20070315 :90A::OFFR//PRCT/100, :16S:CAOPTN
When the details of the entitlement are known, Custodian Bank CUSTUS33 sends an entitlement notification.
MT 564 Corporate Action Notification

Explanation Header Sender Message Type Receiver Message text Sequence A General Information Start of block Corporate action reference Senders reference Function of the message Final maturity Mandatory indicator Details are complete End of block Sequence B Underlying Securities Start of block Underlying securities :16R:USECU :35B:ISIN US345397TT06 Description of the instrument Sequence B2 Account Information :16R:GENL :20C::CORP//RDM3437592 :20C::SEME//1997189-013 :23G:REPE :22F::CAEV//REDM :22F::CAMV//MAND :25D::PROC//COMP :16S:GENL CUSTUS33 564 ABCDUS33 Format
17 December 2008
77
Start of block Safekeeping account Eligible face amount balance End of block End of block Sequence D Corporate Action Details Start of block Redemption date End of block Sequence E Corporate Action Options Start of block CA option number Cash option Currency offered Default option Redemption price (100% par) Sequence E1 Securities Movement Start of block Debit indicator Underlying securities to be debited Quantity to be debited Date securities will be debited End of block Sequence E2 Cash Movement Start of block Credit indicator Gross amount Entitled amount Payment date End of block End of block
:16R:ACCTINFO :97A::SAFE//1234567891 :93B::ELIG//FAMT/100000, :16S:ACCTINFO :16S:USECU
:16R:CADETL :98A::REDM//20070315 :16S:CADETL
:16R:CAOPTN :13A::CAON//001 :22F::CAOP//CASH :11A::OPTN//USD :17B::DFLT//Y :90A::OFFR//PRCT/100,
:16R:SECMOVE :22H::CRDB//DEBT :35B:ISIN US345397TT06 :36B::ENTL//FAMT/100000, :98A::PAYD//20070315 :16S:SECMOVE
:16R:CASHMOVE :22H::CRDB//CRED :19B::GRSS//EUR105900, :19B::ENTL//EUR105900, :98A::PAYD//20070315 :16S:CASHMOVE :16S:CAOPTN
When the payment is done, Custodian Bank CUSTUS33 sends a confirmation message.
MT 566 Corporate Action Confirmation

Explanation Header Sender CUSTUS33 Format
78
Message Type Receiver Message text Sequence A General Information Start of block Corporate action reference Senders reference Function of the message Final maturity End of block Sequence B Underlying Securities Start of block Safekeeping account Underlying securities
566 ABCDUS33
:16R:GENL :20C::CORP//RDM3437592 :20C::SEME//1997189-014 :23G:NEWM :22F::CAEV//REDM :16S:GENL
:16R:USECU :97A::SAFE//1234567891 :35B:ISIN US345397TT06 Description of the instrument
Eligible face amount balance Confirmed balance End of block Sequence C Corporate Action Details Start of block Redemption date Date securities will be debited End of block Sequence D Corporate Action Confirmation Start of block CA option number Cash option Redemption price (100% par) Sequence D1 Securities Movement Start of block Debit indicator Underlying securities to be debited Quantity to be debited Posting date End of block Sequence D2 Cash Movement Start of block
:93B::ELIG//FAMT/100000, :93B::CONB//FAMT/100000, :16S:USECU
:16R:CADETL :98A::REDM//20070315 :98A::PAYD//20070315 :16S:CADETL
:16R:CACONF :13A::CAON//001 :22F::CAOP//CASH :90A::OFFR//PRCT/100,
:16R:SECMOVE :22H::CRDB//DEBT :35B:ISIN US345397TT06 :36B::PSTA//FAMT/100000, :98A::POST//20070315 :16S:SECMOVE
:16R:CASHMOVE
17 December 2008
79
Credit indicator Gross amount Entitled amount Posting date Value date End of block End of block
:22H::CRDB//CRED :19B::GRSS//EUR105900, :19B::PSTA//EUR105900, :98A::POST//20070315 :98A::VALU//20070315 :16S:CASHMOVE :16S:CACONF
80
Trade Standards
Trade Standards
SWIFT offers a range of FIN standards - also called Message Types (MTs) for Trade, the Category 7 types support the processing of documentary credits and guarantees in a bank-tobank environment. In order to reuse these message types, without technical change, in a corporate-to-bank and bank-to-corporate environment, the implementation guidelines specified herein must be followed.
Documentary Credit Flows

The following documentary credit flows are supported.
17 December 2008
81
Guarantee/Standby Letter of Credit Flows

The following guarantee / standby letter of credit flows are supported.
Technical Approach
A set of proprietary messages based on use of the existing MT798 (Proprietary message) has been defined to support the transfer of existing Category 7 messages in a corporate-to-bank and a bank-to-corporate environment. In order to meet the specific requirements for additional components specific to this environment new MT798 messages have also been defined, based on existing MT field types. This approach has; 1) minimised the need for usage guidelines and rules to govern how additional information that otherwise would have needed to be inserted into the existing Category 7 messages structures or in an additional MT799 message(s); 2) provided new message subtypes to specifically identify the individual corporate-to-bank and bank-to-corporate flows; 3) provided flexibility for future extension of the message components and for additional message types. The following figures illustrate the use of the MT798 in the corporate-to-bank and bank-tocorporate environment. The first MT798 is always the Index message. This Index message indicates the function of a set of messages using the MT798 sub-message type code, e.g. 770 Application for documentary credit, 771 - Notification of issuance of Documentary Credit, 774 Advice of Documentary Credit, 761 - Application for issuance of Guarantee / Standby Letter of
82
Trade Standards
Credit, etc. The Index message contains additional fields specific to corporate-to-bank and bankto-corporate flows. The MT798 Index message(s) are followed with further MT798s, the first being the mandatory MT798 Details message that envelopes an existing MT message, e.g. MT700, MT707, MT760, etc. The optional MT798 Extension may follow and may occur several times, enveloping where appropriate additional MT message types, e.g. MT701 or MT711 or MT721. Refer to the Message Tables at the end of the below figures for a detailed breakdown of the permitted structures. A set of messages from a single sender are linked using field 27A (Message Index/Total) and field 21A (Customer Reference Number) or 21P (Advising Bank Reference Number), depending on the message set function), and are supplemented where appropriate with the document reference number, e.g. documentary credit number or guarantee number. Refer below.
17 December 2008
83
84
Trade Standards
17 December 2008
85
Message Tables
Import Documentary Credit MT Message Type SubMessag e Type Status Max. Occur Name Base Message Type
Application for issuance of Documentary Credit - C2B MT798 MT798 MT798 770 700 701 M M O 1 1 3 LC Application Index LC Application Details LC Application Extension MT700 MT701
Notification of issuance of Documentary Credit - B2C MT798 MT798 MT798 771 700 701 M M O 1 1 3 LC Notification of Issuance Index LC Notification of Issuance Details LC Notification of Issuance Extension MT700 MT701
Request for amendment of Documentary Credit - C2B MT798 MT798 772 707 M M 1 1 LC Amendment Request Index LC Amendment Request Details MT707
Notification of amendment of Documentary Credit - B2C MT798 MT798 773 707 M M 1 1 LC Notification of Amendment Index LC Notification of Amendment Details MT707
86
Trade Standards
Export Documentary Credit MT Message Type SubMessag e Type Status Max. Occur Name Base Message Type
Advice of Documentary Credit B2C MT798 MT798 MT798 774 700 701 M M O 1 1 3 LC Advice Index LC Advice Details LC Advice Extension MT700 MT701
Advice of amendment of Documentary Credit B2C MT798 MT798 776 707 M M 1 1 LC Amendment Index LC Amendment Details MT707
Advice of Third Bank Documentary Credit B2C MT798 MT798 MT798 780 710 711 M M 0 1 1 3 LC Third Bank Advice Index LC Third Bank Advice Details LC Third Bank Advice Extension MT710 MT711
Advice of Transfer Documentary Credit B2C MT798 MT798 MT798 782 720 721 M M O 1 1 3 LC Transfer Advice Index LC Transfer Advice Details LC Transfer Advice Extension MT720 MT721
Guarantee / Standby Letter of Credit MT Message Type SubMessage Type Status Max. Occur Name Base Message Type
Application for issuance of Guarantee / Standby Letter of Credit C2B MT798 MT798 761 or 784 760 M M M 1 1 1 Guarantee Application Index Standby LC Application Index Guarantee Request Details MT760
Notification of Guarantee / Standby Letter of Credit B2C MT798 MT798 762 or 785 760 M M M 1 1 1 Guarantee Notification Index Standby LC Notification Index Guarantee Amendment Request Details MT767
Notification of amendment of Guarantee / Standby Letter of Credit B2C MT798 MT798 764 or 787 767 M M M 1 1 1 Guarantee Amendment Notification Index Standby LC Amendment Notification Index Guarantee Amendment Notification Details MT767
Advice of Reduction or Release B2C MT798 MT798 766 769 M M 1 1 Advice of Release / Reduction Index Advice of Release / Reduction Details MT769
17 December 2008
87
MT Message Type
SubMessage Type
Status
Max. Occur
Name
Base Message Type
Free Format Message C2B MT798 MT798 788 799 M M 1 1 Free Format Message Index Free Format Message Details MT799
Notification of Guarantee / Standby Letter of Credit B2C MT798 MT798 789 799 M M 1 1 Free Format Message Index Free Format Message Details MT799
88
Trade Standards
5.1
Import Documentary Credit Transactions

This section covers the documentary credit transactions applicable to corporate entities involved on the import side of the trade process, specifically four transaction sets:
Application for issuance of Documentary Credit Corporate-to-Bank Notification of issuance of Documentary Credit Bank-to-Corporate Request for amendment of Documentary Credit Corporate-to-Bank Notification of amendment of Documentary Credit Bank-to-Corporate
The SWIFT User Handbook, Volume Standards Category 7, Documentary Credits and Guarantees serves as the main document describing the standards. For more information, see this handbook. In addition, the following implementation conventions apply:
There are no network validated rules for the MT798 (Proprietary Message), nor the enveloped message within the MT798. In implementation, the network validated rules as specified in the latest SWIFT User Handbook for the enveloped message (e.g. MT700 Issue of a Documentary Credit) should be adhered to, unless otherwise stated in this section of the guide, Both the usage rules and usage guidelines as specified in the latest SWIFT User Handbook for all enveloped messages should be adhered to, unless otherwise stated in this section of the guide.
The following diagram depicts the import transaction flows:
The following table indicates the composition of the transaction flows:
17 December 2008
89
Import Documentary Credit MT Message Type SubMessage Type Status Max. Occur Name Base Message Type
Application for issuance of Documentary Credit - C2B MT798 MT798 MT798 770 700 701 M M O 1 1 3 LC Application Index LC Application Details LC Application Extension MT700 MT701
Notification of issuance of Documentary Credit - B2C MT798 MT798 MT798 771 700 701 M M O 1 1 3 LC Notification of Issuance Index LC Notification of Issuance Details LC Notification of Issuance Extension MT700 MT701
Request for amendment of Documentary Credit - C2B MT798 MT798 772 707 M M 1 1 LC Amendment Request Index LC Amendment Request Details MT707
Notification of amendment of Documentary Credit - B2C MT798 MT798 773 707 M M 1 1 LC Notification of Amendment Index LC Notification of Amendment Details MT707
The following legend applies for the above table and the subsequent format and field specifications. The full rules for the notation of components inside messages and fields can be found in the SWIFT User Handbook.
Legend Status M O Usage Details DEFN RULE GUID CODE NOTE Format a c n x Mandatory Optional Definition Usage Rule. Must be adhered to Usage Guidance. Recommended practice Applicable Code Values Remark alphabetic, capital letters (A through Z), upper case only alpha-numeric capital letters (upper case), and digits only numeric, digits (0 through 9) only SWIFT X set: ! A to Z a to z 0 to 9 / - ? : ( ) . , + SPACE CrLf
fixed length
90
Trade Standards
decimals, including decimal comma ',' preceding the fractional part. The fractional part may be missing, but the decimal comma must always be present or
Codes
5.1.1
Application for Documentary Credit

The Application for issuance of Documentary Credit is sent by the corporate (applicant) to its bank and comprises a series of MT798 (Proprietary) messages. Collectively these messages are used to initiate the issuance of a documentary credit by the applicants bank according to the terms, and conditions under which the requested credit is to be opened.
Scope
Usage
The series of MT798 messages for one application must comprise:
The first MT798 message identified with a sub-message type of 770 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT700 message, specific to the corporate-to-bank exchange. The second MT798 message identified with a sub-message type of 700 and enveloping one MT700 message. The existing bank-to-bank MT700 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation. In addition, up to a maximum of three MT798 messages may optionally be included, each identified with a sub-message type of 701 and enveloping one MT701 message. The existing bank-to-bank MT701 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document.
An issuing bank, at its discretion, may modify or correct the application data prior to approval to by the applicant. Each MT798 message for a single application must be identified with the same Customer Reference Number, specified as field 21A, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. In instances where a MT700 or MT701 would otherwise exceed 9,800 characters, fields 45A / 45B (Description of Goods and/or Services), 46A / 46B (Documents Required), or 47A / 47B (Additional Conditions) should be distributed across further MT701s such that any single instance of a MT700 or MT701 does not then exceed the limit of 9,800 characters, Refer to section 5.2.1 (Advice of Documentary Credit) for examples. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD. The Application for issuance of Documentary Credit does not constitute an operative credit instrument.
17 December 2008
91
MT 798<770> - LC Application Index

Section 1 - MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<770> this field should be assigned a value by the corporate, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the corporate. 1.2 12 Sub-Message Type 3!n M DEFN: This field is used to specify the sub-message type number to allow a specific sub-message to be identified within the MT798, e.g. 770 (LC Application Index), 700 (LC Application Details), 701 (LC Application Extension). RULE: For MT798<770> the sub-message type must have a fixed value of 770. 1.3 77E Proprietary Message 73x (Text) M DEFN: This field is used to convey the message contents in a format agreed to by the Sender and the Receiver. RULE: For MT798<770> the contents of this field are specified in Section 2 that follows below.
[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<770> the message index number must have a fixed value of 1, e.g. 1/3, or 1/4 or 1/5 depending on the number of 701s.
92
Trade Standards
2.2 2.3
21A 13E
Customer Reference Number Message Creation Date Time Method of Issue
16x 8!n4!n (Date)(Time) 4!c[/35x] (Method)(Additional Information)
M M
DEFN: This field specifies the Application number which has been assigned by the Applicant. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the method by which a documentary credit is to be issued. CODES: TELE = Telecommunication/SWIFT PSTP = Post with pre-advice/SWIFT PSTW = Post without pre-advice/SWIFT COUP = Courier with pre-advice COUW = Courier without pre-advice RULE: For MT798<770> additional information may only be used when the method is COUP or COUW, to optionally specify the name of the courier.
2.4
24D
2.5
53C
Debit Account Number
/34x (Account)
DEFN: This field specifies the number of the account of the Applicant to be used for settlement. GUID: For MT798<770> for accounts serviced in countries that have implemented IBAN, the IBAN should be used to identify the account.
2.6
71A
Bank Charges Payable By
3!a (Code)
DEFN: This field specifies the party(s) responsible for the documentary credit charges. CODES: BEN = Beneficiary pays all charges OUR = Applicant pays all charges SHA = Beneficiary and Applicant share charges OTH = Other arrangement RULE: For MT798<770>, field 73 Charges Information' must be used to specify the additional charges information when code is = OTH. RULE: For MT798<770>, if field 71N (Confirmation Charges Payable By) is used, the confirmation charges are not covered by this field, field 71A.
17 December 2008
93
2.7
73
Charges Information
6*35x (Narrative)
DEFN: This field specifies additional information for the documentary credit charges. RULE: For MT798<770>, must only be used if field 71A 'Bank Charges Payable By' is = OTH.
2.8
25A
Charges Debit Account Number
/34x (Account)
DEFN: This field specifies the number of account of the Applicant to be used for settlement of charges. RULE: For MT798<770>, only used when the charges are to be handled via separate account from the prime debit account specified in field 53C. GUID: For MT798<770> for accounts serviced in countries that have implemented IBAN, the IBAN should be used to identify the account.
2.9
71N
Confirmation Charges Payable By
3!a (Code)
DEFN: This field specifies the party(s) responsible for the documentary credit confirmation charges. CODES: BEN = Beneficiary pays confirmation charges OUR = Applicant pays confirmation charges
2.10
58a
Advising Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
(Party Identifier) (Party Identifier) (Name & Address)
4!a2!a2!c[3!c] (Identifier Code)
DEFN: This field specifies the bank through which the documentary credit is to be advised/confirmed to the beneficiary. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank.
94
Trade Standards
2.11
29T
Transport Mode
4!c[/35x] (Code)(Narrative)
DEFN: This field specifies the mode of transport for the shipment(s) covered by the documentary credit. CODES: AIRT = Air SEAT = Sea RAIL = Rail ROAD = Road MULT = Multimodal OTHR = any other mode of transport such as shipments by both air and sea, which must be specified in narrative (2nd subfield) RULE: For MT798<770> narrative may only be used in combination with 'OTHR' to specify in free text form the transport mode.
2.12
21E
Forward Contract Reference Number Applicant Undertaking
35x (Text) 100*65x (Narrative)
DEFN: This field specifies a reference number of a forward contract used to hedge currency risk. DEFN: This field specifies the undertaking clause of the applicant. DEFN: This field specifies the contact details of the corporate.
2.13
45C
2.14
29A
Customer Contact
4*35x (Narrative)
2.15
72C
Corporate to Bank Information
6*35x (Narrative)
DEFN: This field specifies additional information for the issuing bank.
17 December 2008
95
MT 798<700> - LC Application Details

[n*78x] (Text)
Section 2 Field 77E Structure [MT700] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<770> the message index number must have a fixed value of 2, e.g. 2/3, or 2/4, or 2/5. NOTE: This field is not present in the MT700 Message Reference Guide.
96
Trade Standards
2.2
21A
Customer Reference Number
16x
DEFN: This field specifies the Application number which has been assigned by the Applicant. NOTE: This field is not present in the MT700 Message Reference Guide.
2.3
27
Sequence of Total
1!n/1!n (Number)(Total)
DEFN: This field specifies the number of this message in the series of messages sent for a documentary credit, and the total number of messages in the series. DEFN: This field specifies the type of credit. CODES: IRREVOCABLE | REVOCABLE |IRREVOCABLE TRANSFERABLE | REVOCABLE TRANSFERABLE | IRREVOCABLE STANDBY | REVOCABLE STANDBY | IRREVOC TRANS STANDBY
2.4
40A
Form of Documentary Credit
24x (Type)
2.5
20
Documentary Credit Number
16x
DEFN: This field specifies the documentary credit number which has been assigned by the Sender. RULE: For MT798<700> this field must specify a documentary credit number, pre-assigned by the applicants bank, or a fixed value of NONREF.
2.6
23
Reference to Pre-Advice
16x
DEFN: This field specifies if the documentary credit has been pre-advised. RULE: For MT798<700> this field is not used.
2.7
31C
Date of Issue
6!n (Date)
DEFN: This field specifies the date on which the issuing bank (Sender) considers the documentary credit as being issued. RULE: For MT798<700> this field is not used.
2.8
40E
Applicable Rules
30x[/35x] (Applicable Rules)(Narrative)
DEFN: This field specifies the rules the credit is subject to. CODES: EUCP LATEST VERSION | EUCPURR LATEST VERSION | ISP LATEST VERSION | OTHR | UCP LATEST VERSION | UCPURR LATEST VERSION Note: Narrative may only be used when code is OTHR
17 December 2008
97
2.9
31D
Date and Place of Expiry
6!n29x (Date)(Place)
DEFN: This field specifies the latest date for presentation under the documentary credit and the place where documents may be presented. RULE: For MT798<700> the date must be later than the date in Field 44C (Latest Date of Shipment) GUID: For MT798<700> if the place is not known, the codeword NOTKNOWN should be used
2.10
51a
Applicant Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the bank of the applicant customer, if different from the issuing bank. GUID: For MT798<700> this field is not required.
2.11
50
Applicant
4*35x (Name & Address)
DEFN: This field specifies the party on behalf of which the documentary credit is being issued. DEFN: This field specifies the party in favour of which the documentary credit is being issued. GUID: For MT798<700>, if the Beneficiary account number is specified, Field: 58a (Advising Bank) should also be specified in the MT798<770>.
2.12
59
Beneficiary
[/34x]
(Account
4*35x) (Name & Address)
2.13
32B
Currency Code, Amount
3!a15d (Currency)(Amount)
DEFN: This field contains the currency code and amount of the documentary credit. DEFN: This field specifies the tolerance relative to the documentary credit amount as a percentage plus and/or minus that amount. RULE: MT798<700>, if field 39A is used, field 39B must not be used.
2.14
39A
Percentage Credit Amount Tolerance
2n/2n (Tolerance 1)(Tolerance 2)
2.15
39B
Maximum Credit Amount
13x
DEFN: This field further qualifies the documentary credit amount. CODES: NOT EXCEEDING RULE: MT798<700>, if field 39B is used, field 39A must not be used.
98
Trade Standards
2.16
39C
Additional Amounts Covered
4*35x (Narrative)
DEFN: This field specifies any additional amounts available to the beneficiary under the terms of the credit, such as insurance, freight, interest, etc. GUID: Additional amounts covered, for example, freight costs, interest, insurance.
2.17
41a
Available With ... By ...
A 4!a2!a2!c[3!c] (Identifier Code) 14x D 4*35x 14x (Code) (Name & Address) (Code)
DEFN: This field identifies the bank with which the credit is available (the place for presentation) and an indication of how the credit is available. CODES: BY ACCEPTANCE | BY DEF PAYMENT | BY MIXED PYMT | BY NEGOTIATION | BY PAYMENT GUID: When specified, the bank name may be a specific named bank or may be generically specified using one of the following recommended code words ADVISING BANK | ISSUING BANK | REIMBURSING BANK | ANY BANK | ANY BANK IN. For ANY BANK IN, the address may be used to specify the country, city, etc. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the bank with which the credit is requested to be made available.
2.18
42C
Drafts at ...
3*35x (Narrative)
DEFN: This field specifies the tenor of drafts to be drawn under the documentary credit. GUID: The draft tenor may be a specified using one of the following recommended code words SIGHT | AFTER DRAFT DATE | AFTER SHIPMENT DATE. RULE: For MT798<700>, this field is only used if field 41a Available By is not = BY DEF PAYMENT. Mandatory if field 41a 'Available By' = BY ACCEPTANCE.
2.19
42a
Drawee
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field identifies the drawee of the drafts to be drawn under the documentary credit. RULE: For MT798<700> only used if field 41a 'Available By' is not = BY DEF PAYMENT or not = BY MIXED PYMT. Mandatory if field 42C is used. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the drawee bank.
17 December 2008
99
2.20
42M
Mixed Payment Details
4*35x (Narrative)
DEFN: This field specifies the payment dates, amounts and/or method for their determination in a documentary credit which is available by mixed payment. GUID: The instalment tenor may be specified using one of the following recommended code words SIGHT | AFTER DRAFT DATE | AFTER SHIPMENT DATE. RULE: For MT798<700>, this field is mandatory if field 41a 'Available By' = BY MIXED PYMT.
2.21
42P
Deferred Payment Details
4*35x (Narrative)
DEFN: This field specifies the payment date or method for its determination in a documentary credit which is available by deferred payment only. RULE: For MT798<700>, this field is mandatory if field 41a 'Available By' = BY DEF PAYMENT.
2.22
43P
Partial Shipments
1*35x (Narrative)
DEFN: This field specifies whether or not partial shipments are allowed under the documentary credit. GUID: May be a specified using one of the following recommended code words ALLOWED | NOT ALLOWED.
2.23
43T
Transhipment
1*35x (Narrative)
DEFN: This field specifies whether or not transhipment is allowed under the documentary credit. GUID: May be a specified using one of the following recommended code words ALLOWED | NOT ALLOWED.
2.24
44A
Place of Taking in Charge/Dispatch from .../Place of Receipt
1*65x (Narrative)
DEFN: This field specifies the place of taking in charge (in case of a multimodal transport document), the place of receipt (in case of a road, rail or inland waterway transport document or a courier or expedited delivery service document), the place of dispatch or the place of shipment to be indicated on the transport document. DEFN: This field specifies the port of loading or airport of departure to be indicated on the transport document. DEFN: This field specifies the port of discharge or airport of destination to be indicated on the transport document.
2.25
44E
Port of Loading/Airport of Departure Port of Discharge/Airport of Destination
1*65x (Narrative) 1*65x (Narrative)
2.26
44F
100
Trade Standards
2.27
44B
Place of Final Destination/For Transportation to .../Place of Delivery Latest Date of Shipment
1*65x (Narrative)
DEFN: This field specifies the final destination or place of delivery to be indicated on the transport document.
2.28
44C
6!n (Date)
DEFN: This field specifies the latest date for loading on board/dispatch/taking in charge. DEFN: This field specifies the period of time during which the goods are to be loaded on board/despatched/taken in charge. RULE: For MT798<700>, if field 44C is used, field 44D must not be used.
2.29
44D
Shipment Period
6*65x (Narrative)
2.30
45A
Description of Goods and/or Services
100*65x (Narrative)
DEFN: his field contains a description of the goods and/or services. GUID: Purchase Order details may be repeated, product details (line item) may be repeated per Purchase Order. GUID: INCOTERMS may be a specified using one of the following recommended code words CFR | CIF | CIP | CPT | DAF | DDP | DDU | DEQ | DES | EXW | FAS | FCA | FOB. GUID: Last line of the description should specify the applicable INCOTERM, e.g. CIF HAMBURG.
2.31
46A
Documents Required
100*65x (Narrative)
DEFN: This field contains a description of any documents required. GUID: The document descriptions should be structured as follows: 1) Invoicing documents, 2) Transport Documents, 3) Insurance Documents, 4) Other documents.
2.32
47A
Additional Conditions
100*65x (Narrative)
DEFN: This field contains a description of further conditions of the documentary credit DEFN: This field may be used only to specify charges to be borne by the beneficiary. RULE: For MT798<700> this field is not used.
2.33
71B
Charges
6*35x (Narrative
17 December 2008
101
2.34
48
Period for Presentation
4*35x (Narrative)
DEFN: This field specifies the period of time after the date of shipment within which the documents must be presented for payment, acceptance or negotiation. DEFN: This field contains confirmation instructions for the Receiver. CODES: CONFIRM | MAY ADD | WITHOUT.
2.35
49
Confirmation Instructions
7!x (Instruction)
2.36
53a
Reimbursing Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the name of the bank which has been authorised by the Sender to reimburse drawings under the documentary credit. This may be a branch of the Sender or the Receiver, or an entirely different bank. RULE: For MT798<700> this field is not used.
2.37
78
Instructions to the Paying/Accepting/Negotia ting Bank
12*65x (Narrative)
DEFN: This field specifies instructions to the paying, accepting or negotiating bank. It may also indicate if pre-notification of a reimbursement claim or pre-debit notification to the issuing bank is required. RULE: For MT798<700> this field is not used.
2.38
57a
'Advise Through' Bank
A [/1!a][/34x] C /34x D [/1!a][/34x] 4*35x
(Party Identifier) (Party Identifier) (Party Identifier) (Name & Address)
DEFN: This field identifies the bank, if different from the Receiver, through which the documentary credit is to be advised/confirmed to the beneficiary. RULE: For MT798<700> this field is not used.
2.39
72
Sender to Receiver Information
6*35x (Narrative)
DEFN: This field specifies additional information for the Receiver. RULE: For MT798<700> this field is not used.
102
Trade Standards
MT 798<701> - LC Application Extension

[n*78x] (Text)
17 December 2008
103
Section 2 Field 77E Structure [MT701] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<701> the message index number must start with a value of 3 for the first MT798<701> in the series and be incremented by 1 for each subsequent MT798<701>, e.g. 3/4, 4/4, or 3/5, 4/5, 5/5. NOTE: field is not present in the MT701 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the Application number which has been assigned by the Applicant. NOTE: This field is not present in the MT701 Message Reference Guide. 2.3 27 Sequence of Total 1!n/1!n (Number)(Total) M DEFN: This field specifies the number of this message in the series of messages sent for a documentary credit, and the total number of messages in the series. NOTE: A maximum of 3 MT798<701>s are permitted. 2.4 20 Documentary Credit Number 16x M DEFN: This field specifies the documentary credit number which has been assigned by the Sender. RULE: For MT798<701> this field must specify a documentary credit number, pre-assigned by the applicants bank, or a fixed value of NONREF 2.5 45B Description of Goods and/or Services Documents Required 100*65x (Narrative) 100*65x (Narrative) 2.7 47B Additional Conditions 100*65x (Narrative) O O O DEFN: This field contains a description of the goods and/or services. DEFN: This field contains a description of any documents required. DEFN: This field contains a description of further conditions of the documentary credit.
2.6
46B
104
Trade Standards
Business Example 1
Please note that for the following examples, the assumption is that appropriate agreements have been put in place between the different customer parties and the receiving banks to execute the transfers requested.
Narrative
ABC Company, Kaerntnerstrasse 3, Vienna, imports beer from Amdam Company, PO Box 123, Amsterdam, under a documentary credit. ABC Co.'s bank is Oesterreichische Laenderbank, Vienna. In addition to the above information, the documentary credit application is comprised of the following:
Type of Credit: Documentary Credit Application Number: Expiry Date: Place of Expiry: Amount: Debit Account Advising Bank: IRREVOCABLE 7890123 30-Jul-07 Amsterdam Euro 100,000 1234567891 Amsterdam-Rotterdam Bank Amsterdam Available With: Advising Bank By sight payment Shipment: 400,000 Bottles of beer Packed 12 to an export carton FCA Amsterdam Against presentation of the following documents through the Advising Bank: Signed Commercial Invoice in Quintuplicate Forwarding Agent's Certificate of Receipt, showing goods addressed to Applicant.
Documents are to be presented within 6 days after the date of issuance of the Forwarding Agent's Certificate of Receipt (FCR). Confirmation is requested. Taking in charge at Amsterdam for transportation to Vienna. Transhipment and partial shipments are permitted.
17 December 2008
105
Information Flow
SWIFT Messages SWIFT Message 1 MT798 <770> Explanation Header Sender Message Type Receiver Message text Transaction reference number Sub-message type Proprietary message :20:B09290104112078T :12:770 :77E: :27A:1/2 :21A:7890123 :13E:200701151218 :24D: TELE :53C: 1234567891 :71A:BEN :29A:WILSON PICKET +3224567841 ABCOBEB3 798 OLBNK03L Format
SWIFT Message 2 MT798 <700> Explanation Header Sender Message Type Receiver ABCOBEB3 798 OLBNK03L Format
106
Trade Standards
Message text Transaction reference number Sub-message type Proprietary message :20:B09290104112079T :12:700 :77E: :27A:2/2 :21A:7890123 :27:1/2 :40A:IRREVOCABLE :20:NONREF :40E:UCP LATEST VERSION :31D:070730AMSTERDAM :50:ABC COMPANY KAERNTNERSTRASSE 3 VIENNA :59:AMDAM COMPANY PO BOX 123 AMSTERDAM :32B:EUR100000, :41A:BACOARBA BY PAYMENT :43P:ALLOWED :43T:ALLOWED :44A:AMSTERDAM :44B:VIENNA :45A:+400,000 BOTTLES OF BEER PACKED 12 TO AN EXPORT CARTON +FCA AMSTERDAM :46A:+SIGNED COMMERCIAL INVOICE IN QUINTUPLICATE + FORWARDING AGENTS CERTIFICATE OF RECEIPT SHOWING GOODS ADDRESSED TO THE APPLICANT :48:WITHIN 6 DAYS OF ISSUANCE OF FCR :49:CONFIRM
Business Example 2
Narrative
Solvia AB. PO Box 123, Upsala, Sweden, intends to import computer and electrical parts from Proquinal S.A., 48 rue de la Bourse, Brussels, under a documentary credit. The documentary credit is in US dollars. Solvia AB banks with Skandinaviska Enskilda Banken, Stockholm. Proquinal S.A. banks with Generale Bank, Brussels.
17 December 2008
107
The following information comprises the documentary credit application:

Type of Credit: Documentary Credit Application Number: Expiry Date: Place of Expiry: Amount: Available With: IRREVOCABLE N66758 30 July 2007 Brussels US Dollars 31,500 Advising Bank by acceptance of Beneficiary's draft drawn at 30 days after bill of lading date on Generale Bank 1 2269d 1/2, 2,5 tb-p + 2,5 tb-r disk drive 1 memory rom 210-6298 1 power regulator 210-0341 1 rom t-loading 210-6705 1 power supply regulator 210-6756 1 coss interface 210-7068 1 ribbon assy 279-0181 2 hub lamp assy 726-1021 1 air filter 726-0414 cif Stockholm
Shipment:
Documents Required/Special Conditions:
Signed Commercial Invoice in Sevenfold 2/3 clean on board ocean bills of lading marked freight prepaid consigned to the order of beneficiaries and endorsed in blank, marked notify applicant with full name and address, dated not later than 21 July 2007 copy certificate of origin showing goods of Belgian origin copy consular invoice mentioning import registration number 123 1/2 insurance policy for 110 percent of invoice value, covering all risks and war risks and srcc as per institute cargo clauses, including warehouse to warehouse clause packing list in 4 copies copy of airmail letter addressed to the applicant showing that one original of all documents have been sent directly to them within three days after bill of lading date the certificate of origin may also indicate that goods are of EEC origin instead of Belgian origin drafts are to be marked as drawn under this documentary credit documents must be presented within 10 days after bill of lading date please advise beneficiaries adding your confirmation all documents must be forwarded to us in one lot all charges are for account of the beneficiary except commission related to the acceptance of the draft
Shipment is from Antwerp to Stockholm.
108
Trade Standards
At maturity of the draft, reimbursement is to be claimed at Manufacturers Hanover Trust Company, New York. Transhipment and partial shipments are not allowed. The credit is subject to ICC UCP 600.
Information Flow
SWIFT Messages
Note: The number of characters in the following messages does not exceed the maximum input message length. Four MT798 messages are used to illustrate the use of a combination of enveloped MT700 and MT701 messages.
SWIFT Message 1 MT798 <770> Explanation Header Sender Message Type Receiver Message text Transaction reference number Sub-message type :20:Y067844451 :12:770 SOLCORP3 798 ESSESESS Format
17 December 2008
109
Proprietary message
:77E: :27A:1/4 :21A:N66758 :13E:200701151218 :24D: TELE :53C:9876543211 :71A:OTH :73:ALL CHARGES ARE FOR ACCOUNT OF THE BENEFICIARY EXCEPT COMMISSION RELATED TO THE ACCEPTANCE OF THE DRAFT :29A:BILBO BAGGINS +3224567841
110
Trade Standards
Proprietary message
:77E: :27A:2/4 :21A:N66758 :27:1/3 :40A:IRREVOCABLE :20:DC.IMP 3410/3444 :40E:UCP LATEST VERSION :31D:070730BRUSSELS :50:SOLVIA AB PO BOX 123 UPSALA, SWEDEN :59:PROQUINAL S.A. 48 RUE DE LA BOURSE BRUSSELS :32B:USD31500, :41A:GEBABEBB BY ACCEPTANCE :42C:30 DYS AFTER BLADING :42A:GEBABEBB36A :43P:NOT ALLOWED :43T:NOT ALLOWED :44A:ANTWERP :44B:STOCKHOLM :47A:+THE CERTIFICATE OF ORIGIN MAY ALSO INDICATE THAT GOODS ARE OF EEC ORIGIN INSTEAD OF BELGIAN ORIGIN +DRAFTS ARE TO BE MARKED AS DRAWN UNDER THIS DOCUMENTARY CREDIT :48:DOCUMENTS MUST BE PRESENTED WITHIN 10 DAYS AFTER BILL OF LADING DATE :49:CONFIRM
17 December 2008
111
Proprietary message
:77E: :27A:3/4 :21A:N66758 :27:2/3 :20:NONREF :45B:+1 2269D 1/2, 2,5 TB-P + 2,5 TB-R DISKDRIVE +1 MEMORY ROM 210-6298 +1 POWER REGULATOR 210-0341 +1 ROM T-LOADING 210-6705 +1 POWER SUPPLY REGULATOR 210-6756 +1 COSS INTERFACE 210-7068 +1 RIBBON ASSY 279-0181 +2 HUB LAMP ASSY 726-1021 +1 AIR FILTER 726-0414 +CIF STOCKHOLM
112
Trade Standards
Proprietary message
:77E: :27A:4/4 :21A:N66758 :27:3/3 :20:NONREF :46B:+SIGNED COMMERCIAL INVOICE IN SEVENFOLD +2/3 CLEAN ON BOARD OCEAN BILLS OF LADING MARKED FREIGHT PREPAID CONSIGNED TO THE ORDER OF BENEFICIARY'S AND ENDORSED IN BLANK, MARKED NOTIFY APPLICANT WITH FULL NAME AND ADDRESS, DATED NOT LATER THAN 21 JULY 2007 +COPY CERTIFICATE OF ORIGIN SHOWING GOODS OF BELGIAN ORIGIN +COPY CONSULAR INVOICE MENTIONING IMPORT REGISTRATION NUMBER 123 +1/2 INSURANCE POLICY FOR 110 PERCENT OF INVOICE VALUE, COVERING ALL RISKS AND WAR RISKS AND SRCC AS PER INSTITUTE CARGO CLAUSES, INCLUDING WAREHOUSE TO WAREHOUSE CLAUSE +PACKING LIST IN 4 COPIES +COPY OF AIRMAIL LETTER ADDRESSED TO THE APPLICANT SHOWING THAT ONE ORIGINAL OF ALL DOCUMENTS HAVE BEEN SENT DIRECTLY TO THEM WITHIN THREE DAYS AFTER BILL OF LADING DATE
5.1.2
Scope
Notification of Issuance of Documentary Credit

The Notification of Issuance of Documentary Credit is sent to the corporate (applicant) by its bank and comprises a series of MT798 (Proprietary) messages. Collectively these messages are used to notify the issuance of a documentary credit by the applicants bank and to stipulate the terms, and conditions under which the credit has been opened.
Usage
The series of MT798 messages for one Notification of Issuance must comprise:
The first MT798 message identified with a sub-message type of 771 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT700 message, specific to the bank-to-corporate exchange. The second MT798 message identified with a sub-message type of 700 and enveloping one MT700 message. The existing bank-to-bank MT700 message specification is used, without technical change, but with the implementation governed by a set of additional
17 December 2008
113
usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
In addition, up to a maximum of three MT798 messages may optionally be included, each identified with a sub-message type of 701 and enveloping one MT701 message. The existing bank-to-bank MT701 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document.
Each MT798 message for a single Notification of Issuance must be identified with the same Customer Reference Number as received by the bank from the corporate in the original application. This number is specified in field 21A, the second field encapsulated by field 77E, in the MT798 Notification of Issuance. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD. The Notification of Issuance of Documentary Credit does not constitute an operative credit instrument. The Notification of Issuance of Documentary Credit should only be sent in response to the receipt by the bank of an Application for issuance of Documentary Credit (MT798<770/700/701>).
114
Trade Standards
MT 798<771> - LC Notification of Issuance Index

Section 1 - MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<771> this field should be assigned a value by the bank, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the bank to the same corporate. 1.2 12 Sub-Message Type 3!n M DEFN: This field is used to specify the sub-message type number to allow a specific sub-message to be identified within the MT798, e.g. 770 (LC Application Index), 700 (LC Application Details), 701 (LC Application Extension). RULE: For MT798<771> the sub-message type must have a fixed value of 771. 1.3 77E Proprietary Message 73x (Text) M DEFN: This field is used to convey the message contents in a format agreed to by the Sender and the Receiver. RULE: For MT798<771> the contents of this field are specified in Section 2 that follows below.
[n*78x] (Text)
7 November 2008
115
2.2
21A
Customer Reference Number Documentary Credit Number Message Creation Date Time Issuing Bank
16x
DEFN: This field specifies the related documentary credit application number as received by the bank in the original application from the corporate. DEFN: This field specifies the documentary credit number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the issuing bank. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 of the issuing bank.
2.3 2.4
20 13E
16x 8!n4!n (Date)(Time) A [/1!a][/34x] C /34x (Party Identifier) (Party Identifier) (Party Identifier) (Party Identifier) (Name & Address)
M M
2.5
52a
2.6
58a
Advising Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the advising bank. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank.
2.7
29B
Bank Contact
4*35x (Narrative)
DEFN: This field specifies the contact details of the bank. DEFN: This field specifies additional information for the corporate.
2.8
72C
Bank to Corporate Information
6*35x (Narrative)
MT 798<700> - LC Notification of Issuance Details

Section 1 - MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<700> this field should be assigned a value by the bank, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the bank to the same corporate.
116
Trade Standards
1.2
12
Sub-Message Type
3!n
DEFN: This field is used to specify the sub-message type number to allow a specific sub-message to be identified within the MT798, e.g. 770 (LC Application Index), 700 (LC Application Details), 701 (LC Application Extension). RULE: For MT798<700> the sub-message type must have a fixed value of 700.
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
DEFN: This field is used to convey the message contents in a format agreed to by the Sender and the Receiver. RULE: For MT798<700> the contents of this field are specified in Section 2 that follows below.
Section 2 Field 77E Structure [MT700] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<700> the message index number must have a fixed value of 2, e.g.2/4 NOTE: This field is not present in the MT700 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the related documentary credit application number as received by the bank in the original Application from the corporate. NOTE: This field is not present in the MT700 Message Reference Guide. 2.3 MT700 Message M MT700 message contents.
7 November 2008
117
MT 798<701> - LC Notification of Issuance Extension

[n*78x] (Text)
118
Trade Standards
Section 2 Field 77E Structure [MT701] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<701> the message index number must start with a value of 3 for the first MT798<701> in the series and be incremented by 1 for each subsequent MT798<701>, e.g. 3/4, 4/4, or 3/5, 4/5, 5/5. NOTE: This field is not present in the MT701 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the related documentary credit application number as received by the bank in the original Application from the corporate. NOTE: This field is not present in the MT701 Message Reference Guide. 2.3 MT701 Message M MT701 message contents. NOTE: A maximum of 3 MT798<701>s are permitted.
7 November 2008
119
5.1.3
Scope
Request for Amendment of Documentary Credit

The Request for Amendment of Documentary Credit is sent by the corporate (applicant) to its bank and comprises a series of MT798 (Proprietary) messages. Collectively these messages are used to request amendment/s of the terms and conditions of a credit previously issued by the applicants bank.
Usage
The series of MT798 messages for one Request for Amendment must comprise: The first MT798 message identified with a sub-message type of 772 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT707 message, specific to the corporate-to-bank exchange. The second MT798 message identified with a sub-message type of 707 and enveloping one MT707 message. The existing bank-to-bank MT707 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
Each MT798 message for a single Request for Amendment must be identified with the same Customer Reference Number, specified as field 21A, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD. The Request for Amendment of Documentary Credit does not constitute an operative credit instrument.
120
Trade Standards
MT 798<772> - LC Request for Amendment Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<772> the message index number must have a fixed value of 1, e.g. 1/2. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the amendment reference number which has been assigned by the corporate.
7 November 2008
121
2.3 2.4
20 13E
Documentary Credit Number Message Creation Date Time Method of Issue
16x 8!n4!n (Date)(Time) 4!c[/35x] (Method)(Additional Information)
M M
DEFN: This field specifies the documentary credit number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the method by which a documentary credit amendment is to be issued. CODES: TELE = Telecommunication/SWIFT PSTW = Post COUW = Courier
2.5
24D
RULE: For MT798<772> additional information may only be used when the method is COUW, to optionally specify the name of the courier. 2.6 71A Amendment Bank Charges Payable By 3!a (Code) M DEFN: This field specifies the party(s) responsible for the documentary credit amendment charges. CODES: BEN = Beneficiary pays all charges OUR = Applicant pays all charges SHA = Beneficiary and Applicant share charges OTH = Other arrangement
RULE: For MT798<772>, field 73 Charges Information' must be used to specify the additional charges information when code is = OTH. GUID: To amend the charges for the documentary credit itself, this should be requested in Field 72. 2.7 73 Charges Information 6*35x (Narrative) O DEFN: This field specifies additional information for the documentary credit charges. RULE: For MT798<772>, only used if field 71A 'Bank Charges Payable By' is = OTH. 2.8 29A Customer Contact 4*35x (Narrative) O DEFN: This field specifies the contact details of the corporate.
122
Trade Standards
2.9
72C
6*35x (Narrative)
DEFN: This field specifies additional information for the issuing bank.
MT 798<707> - LC Request for Amendment Details

[n*78x] (Text)
7 November 2008
123
Section 2 Field 77E Structure [MT707] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<707> the message index number must have a fixed value of 2, e.g. 2/2. NOTE: This field is not present in the MT707 Message Reference Guide. 2.2 2.3 21A 20 Customer Reference Number Sender's Reference 16x 16x M M DEFN: This field specifies the amendment reference number which has been assigned by the corporate. DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. RULE: For MT798<707> this field must be the documentary credit number. 2.4 21 Receiver's Reference 16x M DEFN: This field contains the reference number assigned to the documentary credit by the Receiver of the message. RULE: For MT798<707> this field must specify a fixed value of NONREF 2.5 23 Issuing Bank's Reference 16x O DEFN: This field specifies the documentary credit number of the issuing bank. RULE: For MT798<707> this field is not used. 2.6 52a Issuing Bank A [/1!a][/34x] C /34x 2.7 31C Date of Issue 6!n (Date) (Party Identifier) (Party Identifier) O O DEFN: This field is used to identify the issuing bank, when different from the Sender of the message. RULE: For MT798<707> this field is not used. DEFN: This field specifies the date of the original issue of the documentary credit, ie, the date on which the issuing bank considers the credit as being issued. RULE: For MT798<707> this field is not used. 2.8 30 Date of Amendment 6!n (Date) O DEFN: This field specifies the date on which the issuing bank considers the credit as being amended. RULE: For MT798<707> this field is not used.
124
Trade Standards
2.9
26E
Number of Amendment
2n (Number)
DEFN: This field specifies the number which identifies this amendment. RULE: For MT798<707> this number starts at 1 and is incremented by 1 for each subsequent amendment to the same documentary credit.
2.10
59
Beneficiary (before this amendment)
[/34x]
(Account
4*35x) (Name & Address)
DEFN: This field specifies the party in favour of which the documentary credit was issued, or transferred, prior to this amendment. NOTE: For MT798<707>, if beneficiary account number is specified, the account is serviced by the Advising Bank specified in field 58a in the opening MT798<770>.
2.11
31E
New Date of Expiry
E 6!n (Date)
DEFN: This field specifies the new, ie, revised, expiry date for presentation under the documentary credit. GUID: For MT798<707> the date should be after the date in Field 44C (Latest Date of Shipment) in the related 798 <700>
2.12
32B
Increase of Documentary Credit Amount
DEFN: This field contains the currency and amount of an increase in the documentary credit amount. RULE: For MT798<707>, field 32B or field 33B must be present, if field 34B used.
2.13
33B
Decrease of Documentary Credit Amount
DEFN: This field contains the currency code and amount of a decrease in the documentary credit amount. RULE: For MT798<707>, field 32B or field 33B must be present, if field 34B used.
2.14
34B
New Documentary Credit Amount After Amendment
DEFN: This field contains the currency code and total amount of the documentary credit after the amendment, disregarding any drawings. RULE: For MT798<707>, if field 34B used, field 32B or field 33B must be present.
7 November 2008
125
2.15
39A
DEFN: When the credit amount tolerance is being amended, this field specifies the new tolerance relative to the documentary credit amount as a percentage plus and/or minus that amount. RULE: For MT798<707>, if field 39A is used, field 39B must not be used.
2.16
39B
13x (Code)
DEFN: This field specifies the amended qualification of the documentary credit amount. CODES: NOT EXCEEDING RULE: For MT798<707>, if field 39B is used, field 39A must not be used.
2.17
39C
Additional Amounts Covered Place of Taking in Charge/Dispatch from .../Place of Receipt
4*35x (Narrative) 1*65x (Narrative)
DEFN: This field specifies amendments to any additional amounts covered, such as insurance, freight, interest, etc. DEFN: This field specifies amendments to the place of taking in charge (in case of a multimodal transport document), the place of receipt (in case of a road, rail or inland waterway transport document or a courier or expedited delivery service document), the place of dispatch or the place of shipment to be indicated on the transport document. DEFN: This field specifies amendments to the port of loading or airport of departure to be indicated on the transport document. DEFN: This field specifies amendments to the port of discharge or airport of destination to be indicated on the transport document. DEFN: This field specifies amendments to the final destination or place of delivery to be indicated on the transport document.
2.18
44A
2.19
44E
Port of Loading/Airport of Departure Port of Discharge/Airport of Destination Place of Final Destination/For Transportation to .../Place of Delivery
1*65x (Narrative) 1*65x (Narrative) 1*65x (Narrative)
2.20
44F
2.21
44B
2.22
44C
Latest Date of Shipment
6!n (Date)
DEFN: This field specifies amendments to the latest date for loading on board/dispatch/taking in charge.
126
Trade Standards
2.23
44D
Shipment Period
6*65x (Narrative)
DEFN: This field specifies amendments to the period of time during which the goods are to be loaded on board/ despatched/taken in charge. RULE: For MT798<707>, if field 44C is used, field 44D must not be used.
2.24
79
Narrative
35*50x (Narrative)
DEFN: This field specifies amendments to the documentary credit for which there is no other specific field. Second occurrence of field.79 (implemented in SR 2008). DEFN: This field specifies additional information for the Receiver. RULE: For MT798<707> this field is not used.
2.25
79
Narrative
35*50x (Narrative)
2.26
72
6*35x (Narrative)
7 November 2008
127
Business Example 1
Please note that for the following example, the assumption is that appropriate agreements have been put in place between the different customer parties and the receiving banks to execute the transfer requested.
Narrative
Solvia AB., Upsala, Sweden an importer, requests an amendment of a documentary credit issued by Skandinaviska Enskilda Banken. The following changes are requested to the terms and conditions of the documentary credit issued DC.IMP 3410/3444:
The expiry date of the credit has been extended to 30 September 2007. The amount of the credit has been increased by USD 3,250 to USD 34,750. The bill of lading is to be issued not later than 20 September 2007.
Information Flow
SWIFT Messages SWIFT Message 1 MT798 <772> Explanation Header Sender Message Type Receiver Message text Transaction reference number Sub-message type :20:Y8967851 :12:772 ESSESESS 798 GEBABEBB Format
128
Trade Standards
Proprietary message
:77E: :27A:1/2 :21A:N66758 :20:DC.IMP 3410/3444 :13E:200701151218 :24D: TELE :71A:BEN
SWIFT Message 2 MT798 <707> Explanation Header Sender Message Type Receiver Message text Transaction reference number Sub-message type Proprietary message :20:Y8967852 :12:707 :77E: :27A:2/2 :21A:7890123 :20:DC.IMP 3410/3444 :21:NONREF :30:070521 :26E:01 :59:PROQUINAL S.A. 48 RUE DE LA BOURSE BRUSSELS :31E:070930 :32B:USD3250, :34B:USD34750, :79:BILLS OF LADING TO BE ISSUED NOT LATER THAN 20 SEPTEMBER 2007 ESSESESS 798 GEBABEBB Format
5.1.4
Scope
Notification of Amendment of Documentary Credit

The Notification of Amendment of Documentary Credit is sent to the corporate (applicant) by its bank and comprises a series of MT798 (Proprietary) messages. Collectively these messages are used to notify the issuance of a documentary credit amendment by the applicant bank according to the applicants instruction received.
Usage
The series of MT798 messages for one Notification of Amendment must comprise:
7 November 2008
129
The first MT798 message identified with a sub-message type of 773 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT707 message, specific to the bank-to-corporate exchange. The second MT798 message identified with a sub-message type of 707 and enveloping one MT707 message. The existing bank-to-bank MT707 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
Each MT798 message for a single Notification of Amendment must be identified with the same Customer Reference Number as received by the bank from the corporate in the original amendment request. This number is specified in field 21A, the second field encapsulated by field 77E, in the MT798 Notification of Amendment. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD. The Notification of Amendment of Documentary Credit does not constitute an operative credit instrument. The Notification of Amendment of Documentary Credit should only be sent in response to the receipt by the bank of a Request for Amendment of Documentary Credit (MT798<772/707>).
130
Trade Standards
MT 798<773> - LC Notification of Amendment Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<773> the message index number must have a fixed value of 1, e.g. 1/2.
7 November 2008
131
2.2
21A
Customer Reference Number Documentary Credit Number Message Creation Date Time Bank Contact
16x
DEFN: This field specifies the related documentary credit amendment number as received by the bank in the original application from the corporate. DEFN: This field specifies the documentary credit number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the contact details of the bank. DEFN: This field specifies additional information for the corporate.
2.3 2.4
20 13E
16x 8!n4!n (Date)(Time) 4*35x (Narrative)
M M
2.5
29B
2.6
72C
6*35x (Narrative)
MT 798<707> - LC Notification of Amendment Details

Section 1 - MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<707> this field should be assigned a value by the bank, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the bank to the same corporate. 1.2 12 Sub-Message Type 3!n M DEFN: This field is used to specify the sub-message type number to allow a specific sub-message to be identified within the MT798, e.g. 770 (LC Application Index), 700 (LC Application Details), 701 (LC Application Extension). RULE: For MT798<707> the sub-message type must have a fixed value of 707.
132
Trade Standards
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT707] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<707> the message index number must have a fixed value of 2, e.g. 2/2. NOTE: This field is not present in the MT707 Message Reference Guide. 2.2 21A Customer Reference Number MT707 Message 16x M DEFN: This field specifies the related documentary credit amendment number as received by the bank in the original application from the corporate. MT707 message contents. RULE: For MT798<707> in field 20 (Sender's Reference), this must specify the documentary credit number.
2.3
7 November 2008
133
5.2
Export Letter of Credit Transactions

This section covers the documentary credit transactions applicable to corporate entities involved on the export side of the trade process, specifically four transaction sets:
Advice of Documentary Credit Bank-to-Corporate Advice of Amendment of Documentary Credit Bank-to-Corporate Advice of Third Bank Documentary Credit Bank-to-Corporate Advice of Transfer Documentary Credit Bank-to-Corporate
There are no network validated rules for the MT798 (Proprietary Message), nor the enveloped message within the MT798. In implementation, the network validated rules as specified in the latest SWIFT User Handbook for the enveloped message (e.g. MT700 Issue of a Documentary Credit) should be adhered to, unless otherwise stated in this section of the guide, Both the usage rules and usage guidelines as specified in the latest SWIFT User Handbook for the enveloped message should be adhered to, unless otherwise stated in this section of the guide.
The following diagram depicts the export transaction flows:
134
Trade Standards

Export Documentary Credit MT Message Type SubMessage Type Status Max. Occur Name Base Message Type
Advice of Documentary Credit B2C MT798 MT798 MT798 774 700 701 M M O 1 1 3 LC Advice Index LC Advice Details LC Advice Extension MT700 MT701
Advice of amendment of Documentary Credit B2C MT798 MT798 776 707 M M 1 1 LC Amendment Index LC Amendment Details MT707
Advice of Third Bank Documentary Credit B2C MT798 MT798 MT798 780 710 711 M M O 1 1 3 LC Third Bank Advice Index LC Third Bank Advice Details LC Third Bank Advice Extension MT710 MT711
Advice of Transfer Documentary Credit B2C MT798 MT798 MT798 782 720 721 M M O 1 1 3 LC Transfer Advice Index LC Transfer Advice Details LC Transfer Advice Extension MT720 MT721
Legend Status M O Usage Details DEFN RULE GUID CODE NOTE Format a c n x Mandatory Optional Definition Usage Rule. Must be adhered to Usage Guidance. Recommended practice Applicable Code Values Remark alphabetic, capital letters (A through Z), upper case only alpha-numeric capital letters (upper case), and digits only numeric, digits (0 through 9) only SWIFT X set: ! A to Z a to z 0 to 9 / - ? : ( ) . , + SPACE CrLf
fixed length
7 November 2008
135
decimals, including decimal comma ',' preceding the fractional part. The fractional part may be missing, but the decimal comma must always be present or
Codes
5.2.1
Scope
Advice of Documentary Credit

The LC Advice of Documentary Credit is sent to the corporate (beneficiary) by its bank and comprises a series of MT798 (Proprietary) messages. Collectively these messages are used to advise the issuance of a documentary credit and the related terms, and conditions under which the credit has been opened.
Usage
The series of MT798 messages for one advice must comprise:
The first MT798 message identified with a sub-message type of 774 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT700 message, specific to the bank-to-corporate exchange. In addition, a MT798 message identified with a sub-message type of 700 and enveloping one MT700 message must be included. The existing bank-to-bank MT700 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable bank-to corporate implementation. In addition, up to a maximum of three MT798 messages may optionally be included, each identified with a sub-message type of 701 and enveloping one MT701 message. The existing bank-to-bank MT701 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document.
An advising bank, at its discretion, may delete bank-to-bank specific data from the MT700 prior to advising it to the beneficiary. Each MT798 message for a single advice must be identified with the same Advising Bank Reference Number and this must be specified in field 21P, the second field encapsulated by field 77E in the MT798. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. In instances where the source MT700 or MT701 exceeds 9,800 characters, fields 45A / 45B (Description of Goods and/or Services), 46A / 46B (Documents Required), or 47A / 47B (Additional Conditions) should be redistributed across further MT701s such that any single instance of a MT700 or MT701 does not then exceed the limit of 9,800 characters, Example 1. MT700 MT701 MT700 45A + 46A 47B 45A Exceeds 9,800 characters
becomes
136
Trade Standards
MT701 MT701
46B 47B
Example 2. MT700 MT700 MT701 MT701 45A + 46A +47A 45A 46B 47B Exceeds 9,800 characters becomes
Example 3. MT700 MT701 MT700 MT701 MT701 45A 46B + 47B 45A 46B 47B Exceeds 9,800 characters
becomes
Example 4. MT700 MT701 MT700 MT701 MT701 MT701 45B 46B 47B 45A 46B + 47B Exceeds 9,800 characters Exceeds 9,800 characters
becomes
7 November 2008
137
MT 798<774> - LC Advice Index

[n*78x] (Text)
138
Trade Standards
2.2
21P
Advising Bank Reference Number Documentary Credit Number Message Creation Date Time Date of Issue
16x
DEFN: This field specifies the reference number which has been assigned by the advising bank to the documentary credit. DEFN: This field specifies the documentary credit number which has been assigned by the issuing bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the date on which the issuing bank considers the documentary credit as being issued. GUID: MT798<774> If field 31C is present in the MT700 then this date must be the same as in the MT700. If field 31C is not present in the MT700 then the date of transmission of the MT700 by the issuing bank should be used.
2.3 2.4
20 13E
16x 8!n4!n (Date)(Time) 6!n (Date)
M M
2.5
31C
2.6
52a
Issuing Bank
A [/1!a][/34x] C /34x
(Party Identifier) (Party Identifier)
DEFN: This field specifies the name of the bank which issued the documentary credit. RULE: For MT798<774>, when specified, the identifier code must be the SWIFT BIC8 or BIC11 for the issuing bank.
2.7
58a
Advising Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the name of the bank which is advising the documentary credit.. RULE: For MT798<774>, when specified, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank.
2.8
29A
Advising Bank Contact
4*35x (Narrative)
DEFN: This field specifies the contact details of the advising bank. DEFN: This field specifies the reference number which has been assigned by the beneficiary to the documentary credit.
2.9
21A
16x
7 November 2008
139
2.10
49D
Confirmation Indicator
7!x (Instruction)
DEFN: This field indicates whether documentary credit has been confirmed. CODES: CONFIRM = Confirmed WITHOUT = Without confirmation
2.11
49F
Confirmation Information
50*65x (Narrative)
DEFN: Additional information concerning confirmation of the documentary credit advice. DEFN: Additional information concerning billing.
2.12
49G
Charges Information
50*65x (Narrative)
2.13
47E
Information from Advising Bank
100*65x (Narrative)
DEFN: Additional information from the advising bank related to the documentary credit advice.
MT 798<700> - LC Advice Details

140
Trade Standards
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT700] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. NOTE: This field is not present in the MT700 Message Reference Guide. 2.2 21P Advising Bank Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the advising bank to the documentary credit. NOTE: This field is not present in the MT700 Message Reference Guide. 2.3 MT700 Message M MT700 message contents.
MT 798<701> - LC Advice Extension

7 November 2008
141
1.2
12
Sub-Message Type
3!n
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT701] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. NOTE: This field is not present in the MT701 Message Reference Guide. 2.2 21P Advising Bank Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the advising bank to the documentary credit. NOTE: This field is not present in the MT701 Message Reference Guide. 2.3 MT701 Message M MT701 message contents. NOTE: A maximum of 3 MT798<701>s are permitted.
142
Trade Standards
Business Example 1
Please note that for the following examples, the assumption is that appropriate agreements have been put in place between the different customer parties and the receiving banks to execute the transfer requested.
Narrative
ABC Company, Kaerntnerstrasse 3, Vienna, imports beer from Amdam Company, PO Box 123, Amsterdam, under a documentary credit. ABC Co.'s bank is Oesterreichische Laenderbank, Vienna. Amdam Co.'s bank is AmsterdamRotterdam Bank, Rotterdam. In addition to the above information, the documentary credit application is comprised of the following:
Type of Credit: Documentary Credit Application Number: Issuing Bank: IRREVOCABLE 7890123 ANZ Bank Melbourne, Australia Expiry Date: Place of Expiry: Amount: Debit Account Advising Bank: 30-Jul-07 Amsterdam Euro 100,000 1234567891 Amsterdam-Rotterdam Bank Amsterdam Available With: Advising Bank By sight payment Shipment: 400,000 Bottles of beer Packed 12 to an export carton FCA Amsterdam Against presentation of the following documents through the Advising Bank:
Signed Commercial Invoice in Quintuplicate

Forwarding Agent's Certificate of Receipt, showing goods addressed to Applicant.
Documents are to be presented within 6 days after the date of issuance of the Forwarding Agent's Certificate of Receipt (FCR). Confirmation is requested. Taking in charge at Amsterdam for transportation to Vienna. Transhipment and partial shipments are permitted.
7 November 2008
143
Information Flow
SWIFT Messages SWIFT Message 1 MT798 <774> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type Proprietary message :20:G9975-98761 :12:774 :77E: :27A:1/2 :21P:ASD88701 :20:DC123456 :13E:200701151218 :31C:070517 :52A:ANZBNK8M :58A:ARBNKN6L :29A:AMSTERDAM-ROTTERDAM BANK MERSTER STRAAT PH 788 677 678 :49D:CONFIRM :47E:+PLEASE PRESENT DOCUMENTS AT ROTTERDAM NORTH BRANCH +MERSTER STRAAT Format ARBNKN6L 798 AMDCORP3
144
Trade Standards
SWIFT Message - 2 MT798 <700> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type Proprietary message :20:G9975-98762 :12:700 :77E: :27A:2/2 :21P: ASD88703 :27:1/1 :40A:IRREVOCABLE :20: DC123456 :23:PREADDV/030510 :31C:070517 :40E:UCP LATEST VERSION :31D:070730AMSTERDAM :50:ABC COMPANY KAERNTNERSTRASSE 3 VIENNA :59:AMDAM COMPANY PO BOX 123 AMSTERDAM :32B:EUR100000, :41A: BACOARBA BY PAYMENT :43P:ALLOWED :43T:ALLOWED :44A:AMSTERDAM :44B:VIENNA :45A:+400,000 BOTTLES OF BEER PACKED 12 TO AN EXPORT CARTON +FCA AMSTERDAM :46A:+SIGNED COMMERCIAL INVOICE IN QUINTUPLICATE + FORWARDING AGENTS CERTIFICATE OF RECEIPT SHOWING GOODS ADDRESSED TO THE APPLICANT :48:WITHIN 6 DAYS OF ISSUANCE OF FCR :49:CONFIRM Format ARBNKN6L 798 AMDCORP3
7 November 2008
145
5.2.2
Scope
Advice of Amendment of Documentary Credit

The LC Advice of Amendment of Documentary Credit is sent to the corporate (beneficiary) by its bank and comprises a series of MT798 (Proprietary) messages. Collectively these messages are used to advise amendments to an opened documentary credit.
Usage
The first MT798 message identified with a sub-message type of 776 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT707 message, specific to the bank-to-corporate exchange. In addition, a MT798 message identified with a sub-message type of 707 and enveloping one MT707 message must be included. The existing bank-to-bank MT707 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable bank-to corporate implementation.
Each MT798 message for a single amendment advice must be identified with the same Advising Bank Reference Number and this must be specified in field 21P, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD.
146
Trade Standards
MT 798<776> - LC Amendment Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<776> the message index number must have a fixed value of 1, e.g. 1/3.
7 November 2008
147
2.2
21P
16x
DEFN: This field specifies the reference number which has been assigned by the advising bank to the documentary credit amendment. DEFN: This field specifies the documentary credit number which has been assigned by the issuing bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the date on which the issuing bank considers the documentary credit as being issued. GUID: MT798<776> If field 31C is present in the MT700 then this date must be the same as in the MT700. If field 31C is not present in the MT700 then the date of transmission of the MT700 by the issuing bank should be used.
2.3 2.4
20 13E
M M
2.5
31C
2.6
52a
Issuing Bank
A [/1!a][/34x] C /34x
DEFN: This field specifies the name of the bank which issued the amendment. RULE: For MT798<776>, when specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the issuing bank.
2.7
58a
Advising Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
(Party Identifier) (Party Identifier) (Name & address)
DEFN: This field specifies the name of the bank which is advising the amendment advice. RULE: For MT798<776>, when specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank.
2.8
29A
4*35x (Narrative)
DEFN: This field specifies the contact details of the advising bank. DEFN: This field specifies the reference number which has been assigned by the beneficiary to the documentary credit. DEFN: This field indicates whether amendment advice has been confirmed. CODES: CONFIRM | WITHOUT.
2.9
21A
Customer Reference Number Confirmation Indicator
16x
2.10
49D
7!x (Instruction)
148
Trade Standards
2.11
49F
50*65x (Narrative)
DEFN: Additional information concerning confirmation of the amendment advice. DEFN: Additional information concerning bank charges. DEFN: Additional information from the advising bank related to the amendment advice.
2.12
49G
Charges Information
50*65x (Narrative)
2.13
47E
100*65x (Narrative)
MT 798<707> - LC Amendment Details

[n*78x] (Text)
7 November 2008
149
Section 2 Field 77E Structure [MT707] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. NOTE: This field is not present in the MT707 Message Reference Guide. 2.2 21P Advising Bank Reference Number MT707 Message 16x M DEFN: This field specifies the reference number which has been assigned by the advising bank to the documentary credit amendment. MT707 message contents.
2.3
150
Trade Standards
5.2.3
Scope
Advice of Third Bank Documentary Credit

The LC Advice of Third Bank Documentary Credit is sent to the corporate (beneficiary) by their bank and comprises a series of MT798 (Proprietary) messages. Collectively these messages are used to advise the issuance of a third bank documentary credit and the related terms and conditions under which the credit has been issued.
Usage
The series of MT798 messages for one third bank advice must comprise:
The first MT798 message identified with a sub-message type of 780 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT710 message, specific to the bank-to-corporate exchange. In addition, a MT798 message identified with a sub-message type of 710 and enveloping one MT710 message must be included. The existing bank-to-bank MT710 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable bank-to corporate implementation. In addition up to a maximum of three MT798 messages may optionally be included, each identified with a sub-message type of 711 and enveloping one MT711 message. The existing bank-to-bank MT711 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document.
Each MT798 message for a single third bank advice must be identified with the same Advising Bank Reference Number and this must be specified in field 21P, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Refer to section 5.2.1 (Advice of Documentary Credit) for elaboration on the approach to address instances where a source MT710 or MT711 exceeds 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD.
7 November 2008
151
MT 798<780> - LC Third Bank Advice Index

[n*78x] (Text)
152
Trade Standards
2.2
21P
16x
DEFN: This field specifies the reference number which has been assigned by the second advising bank to the documentary credit. DEFN: This field specifies the documentary credit number which has been assigned by the issuing bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the date on which the issuing bank considers the documentary credit as being issued. GUID: MT798<780>This date must be the same as the field 31C (Date of Issue) in the MT710.
2.3 2.4
20 13E
M M
2.5
31C
2.6
52a
Issuing Bank
A [/1!a][/34x] C /34x
DEFN: This field specifies the name of the bank which issued the documentary credit. RULE: For MT798<780>, when specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the issuing bank.
2.7
58a
Advising Bank
A [/1!a][/34x] D /1!a][/34x] 4*35x
DEFN: This field specifies the name of the bank which is advising the documentary credit to the beneficiary, i.e. the name of the second advising bank. RULE: For MT798<780>, when specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the second advising bank.
2.8
29A
4*35x (Narrative)
DEFN: This field specifies the contact details of the second advising bank. DEFN: This field specifies the name of the first advising bank involved in processing the documentary credit. RULE: For MT798<780>, when specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the first advising bank.
2.9
56a
First Advising Bank
A [/1!a][/34x] C /34x D [/1!a][/34x] 4*35x
(Party Identifier) (Party Identifier) (Party Identifier) (Name & Address)
7 November 2008
153
2.10
21B
First Advising Bank Reference Number Customer Reference Number Confirmation Indicator
16x
DEFN: This field specifies the reference number which has been assigned by the first advising bank to the documentary credit. DEFN: This field specifies the reference number which has been assigned by the beneficiary to the documentary credit. DEFN: This field indicates whether documentary credit has been confirmed. CODES: CONFIRM | WITHOUT.
2.11
21A
16x
2.12
49D
7!x (Instruction)
2.13
49F
50*65x (Narrative)
DEFN: Additional information concerning confirmation of the documentary credit advice. DEFN: Additional information concerning bank charges. DEFN: Additional information from the second advising bank related to the documentary credit advice.
2.14
49G
Charges Information
50*65x (Narrative)
2.15
47E
100*65x (Narrative)
MT 798<710> - LC Third Bank Advice Details

154
Trade Standards
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT710] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. NOTE: This field is not present in the MT710 Message Reference Guide. 2.2 21P Advising Bank Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the second advising bank to the documentary credit. NOTE: This field is not present in the MT710 Message Reference Guide. 2.3 MT710 Message M MT710 message contents.
MT 798<711> - LC Third Bank Advice Extension

7 November 2008
155
1.2
12
Sub-Message Type
3!n
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT711] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. NOTE: This field is not present in the MT711 Message Reference Guide. 2.2 21P Advising Bank Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the second advising bank to the documentary credit. NOTE: This field is not present in the MT711 Message Reference Guide. 2.3 MT711 Message M MT711 message contents. NOTE: A maximum of 3 MT798<711>s are permitted.
156
Trade Standards
5.2.4
Scope
Advice of Transfer Documentary Credit

The LC Transfer Advice of Documentary Credit is sent to the corporate (beneficiary) by their bank and comprises a series of MT798 (Proprietary) messages. Collectively these messages are used to advise the transfer of a documentary credit and the related terms and conditions under which the credit has been transferred.
Usage
The first MT798 message identified with a sub-message type of 782 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT720 message, specific to the bank-to-corporate exchange. In addition, MT798 message identified with a sub-message type of 720 and enveloping one MT720 message must be included. The existing bank-to-bank MT720 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable bank-to corporate implementation. In addition up to a maximum of three MT798 messages may optionally be included, each identified with a sub-message type of 721 and enveloping one MT721 message. The existing bank-to-bank MT721 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document.
Each MT798 message for a single transfer advice must be identified with the same Advising Bank Reference Number and this must be specified in field 21P, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Refer to section 5.2.1 (Advice of Documentary Credit) for elaboration on the approach to address instances where a source MT720 or MT721 exceeds 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD.
7 November 2008
157
MT 798<782> - LC Transfer Advice Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<782> the message index number must have a fixed value of 1, e.g. 1/3 or 1/4 or 1/5 depending on the number of 721s.
158
Trade Standards
2.2
21P
16x
DEFN: This field specifies the reference number which has been assigned by the advising bank to the documentary credit. DEFN: This field specifies the documentary credit number which has been assigned by the issuing bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the date on which the issuing bank considers the documentary credit as being issued. GUID: MT798<782> If field 31C is present in the MT720 then this date must be the same as in the MT720. If field 31C is not present in the MT720 then the date of transmission of the MT720 by the issuing bank should be used.
2.3 2.4
20 13E
M M
2.5
31C
2.6
52a
Issuing Bank
A [/1!a][/34x] C /34x
Party Identifier) (Party Identifier)
DEFN: This field specifies the name of the bank which issued the documentary credit. RULE: For MT798<782>, when specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the issuing bank.
2.7
58a
Advising Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the name of the bank which is advising the documentary credit. RULE: For MT798<782>, when specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank.
2.8
29A
4*35x (Narrative)
DEFN: This field specifies the contact details of the advising bank. DEFN: This field specifies the name of the transferring bank involved in processing the documentary credit. RULE: For MT798<782>, when specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the transferring bank.
2.9
55a
Transferring Bank
A [/1!a][/34x] B [/1!a][/34x] [35x] D [/1!a][/34x] 4*35x
(Party Identifier) (Party Identifier) (Location) (Party Identifier) (Name & Address)
7 November 2008
159
2.10
21N
Transferring Bank Reference Number Customer Reference Number Confirmation Indicator
16x
DEFN: This field specifies the reference number which has been assigned by the transferring bank to the documentary credit. DEFN: This field specifies the reference number which has been assigned by the 2nd beneficiary to the documentary credit. DEFN: This field indicates whether documentary credit has been confirmed. CODES: CONFIRM | WITHOUT.
2.11
21A
16x
2.12
49D
7!x (Instruction)
2.13
49F
50*65x (Narrative)
DEFN: Additional information concerning confirmation of the documentary credit advice. DEFN: Additional information concerning bank charges. DEFN: Additional information from the advising bank related to the transferred documentary credit.
2.14
49G
Charges Information
50*65x (Narrative)
2.15
47E
100*65x (Narrative)
MT 798<720> - LC Transfer Advice Details

160
Trade Standards
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT720] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. NOTE: This field is not present in the MT720 Message Reference Guide. 2.2 21P Advising Bank Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the advising bank to the documentary credit. NOTE: This field is not present in the MT720 Message Reference Guide. 2.3 MT720 Message M MT720 message contents.
MT 798<721> - LC Transfer Advice Extension

7 November 2008
161
1.2
12
Sub-Message Type
3!n
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT721] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. NOTE: This field is not present in the MT721 Message Reference Guide. 2.2 21P Advising Bank Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the advising bank to the documentary credit. NOTE: This field is not present in the MT700 Message Reference Guide. 2.3 MT721 Message M MT721 message contents. NOTE: A maximum of 3 MT798<721>s are permitted.
162
Trade Standards
5.3
Guarantee / Standby Letter of Credit Transactions

This section covers both Guarantee and Standby Letter of Credit (LC) transactions applicable to corporate entities involved in the trade process, specifically five transaction sets:
Application for issuance of Guarantee / Standby Letter of Credit Corporate-to-Bank Notification of the Issue of, or the Request to a third bank for, a Guarantee / Standby Letter of Credit Bank-to-Corporate Request for Amendment of Guarantee / Standby Letter of Credit Corporate-to-Bank Notification of the Issue of, or the Request to a third bank for, an Amendment of Guarantee / Standby Letter of Credit Bank-to-Corporate Advice of Reduction / Release Bank-to-Corporate
The following diagram depicts the transaction flows:
7 November 2008
163

Guarantee / Standby Letter of Credit MT Message Type SubMessage Type Status Max. Occur Name Base Message Type
Application for issuance of Guarantee / Standby Letter of Credit C2B MT798 761 or 784 MT798 760 M M M 1 1 1 Guarantee Application Index Standby LC Application Index Guarantee Request Details MT760
Notification of Guarantee / Standby Letter of Credit B2C MT798 762 or 785 MT798 760 M M M 1 1 1 Guarantee Notification Index Standby LC Notification Index Guarantee Notification Details MT760
Request for amendment of Guarantee / Standby Letter of Credit C2B MT798 763 or 786 MT798 767 M M M 1 1 1 Guarantee Amendment Request Index Standby LC Amendment Request Index Guarantee Amendment Request Details MT767
Notification of amendment of Guarantee / Standby Letter of Credit B2C MT798 764 or 787 MT798 767 M M M 1 1 1 Guarantee Amendment Notification Index Standby LC Amendment Notification Index Guarantee Amendment Notification Details MT767
Advice of Reduction or Release B2C MT798 MT798 766 769 M M 1 1 Advice of Release / Reduction Index Advice of Release / Reduction Details MT769
Legend Status M O Usage Details DEFN RULE GUID CODE NOTE Format a c n Mandatory Optional Definition Usage Rule. Must be adhered to Usage Guidance. Recommended practice Applicable Code Values Remark alphabetic, capital letters (A through Z), upper case only alpha-numeric capital letters (upper case), and digits only numeric, digits (0 through 9) only
164
Trade Standards
SWIFT X set: A to Z a to z 0 to 9 / - ? : ( ) . , + SPACE CrLf
! d
fixed length decimals, including decimal comma ',' preceding the fractional part. The fractional part may be missing, but the decimal comma must always be present or
Codes
5.3.1
Scope
Application for Issuance of Guarantee / Standby Letter of Credit

The Application for issuance of Guarantee / Standby Letter of Credit is sent by the corporate (Applicant) to its bank and comprises at least two MT798 (Proprietary) messages. For a direct guarantee, these messages serve as a request to the bank to issue a SURETY, a SURETY ON FIRST DEMAND, or a GUARANTEE on behalf of the corporate and in favour of the Beneficiary. If applicable, the request may indicate that the guarantee is to be advised to the Beneficiary via a third-party bank, normally in the beneficiary's country of domicile (i.e. Advising Bank). For an indirect guarantee, these messages serve as an instruction to the bank to issue a request to a Corresponding Bank to issue a guarantee in favour of the Beneficiary in return for its counter-liability and counter-guarantee. For a standby letter of credit, these messages serve as a request to the bank to issue a STANDBY LETTER OF CREDIT on behalf of the corporate and in favour of the Beneficiary. If applicable, the request may indicate that the standby letter of credit is to be advised to the Beneficiary via a third-party bank, normally in the beneficiary's country of domicile (i.e. Advising Bank).
Usage
A single Request for Guarantee / Standby Letter of Credit must comprise:
The first MT798 message identified with a sub-message type of 761 in the case of a guarantee or a sub-message type of 784 in the case of a standby letter of credit, and enveloping one proprietary index message. These proprietary messages contain additional data not covered in the MT760 message, specific to the corporate-to-bank exchange. The second MT798 message identified with a sub-message type of 760 and enveloping one MT760 message. The existing bank-to-bank MT760 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
Each MT798 message for a single Guarantee / Standby Letter of Credit must be identified with the same Customer Reference Number, specified as field 21A, the second field encapsulated by field 77E in the MT798.
7 November 2008
165
Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD.
166
Trade Standards
MT 798<761> - Application for issuance of Guarantee Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<761> The message index number must have a fixed value of 1, e.g. 1/3 or 1/4 or 1/5 depending on the number of 760s.
7 November 2008
167
2.2 2.3
21A 13E
Customer Reference Number Message Creation Date Time Kind of Guarantee
16x 8!n4!n (Date)(Time) 4!c (Code)
M M
DEFN: This field specifies the reference number which has been assigned by the customer. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the kind of the guarantee. CODES: GUAR = GUARANTEE STLC = STANDBY LETTER OF CREDIT SPDM = SURETY PAYABLE ON FIRST DEMAND SURT = SURETY
2.4
22D
2.5
22K
Type of Guarantee
4!c[/35x] (Type of Guarantee)(Narrative)
DEFN: This field specifies the type of the guarantee. CODES: TEND = TENDER GUARANTEE ADVP = ADVANCE PAYMENT GUARANTEE PGDO = PERFORMANCE GUARANTEE (DELIVERY OBLIGATION) PGWO = PERFORMANCE GUARANTEE (WARRANTY OBLIGATION) PGCO = PERFORMANCE GUARANTEE (CONTRACTUAL OBLIGATION) PAYM = PAYMENT GUARANTEE CRED = CREDIT FACILITIES GUARANTEE BILL = BILL OF LADING GUARANTEE LEAS = LEASE GUARANTEE CUST = CUSTOMS GUARANTEE OTHR = any other guarantee type, which must be specified in narrative (2nd subfield) RULE: For MT798<761> narrative may only be used in combination with 'OTHR' to specify in free text form the type of guarantee.
168
Trade Standards
2.6
22E
Form of Guarantee
4!c (Code)
DEFN: This field specifies the form of the guarantee. CODES: DIRC = DIRECT INDC = INDIRECT
2.7
22J
Wording of Guarantee
4!c (Code)
DEFN: This field specifies the type of wording of the guarantee. CODES: STND = STANDARD WORDING OF ISSUING BANK WDAP = WORDING DRAFTED BY APPLICANT WDBF = WORDING DRAFTED BY BENEFICIARY If this field consists of WDAP or WDBF, field 77C of MT798<760> must be used to specify the body text.
2.8
22B
Special Terms
4!c (Code)
DEFN: This field specifies any special terms that should apply to the guarantee in case that the wording of the guarantee should be the standard wording of the Issuing Bank. CODES EFCT = INCL. TERMS OF EFFECTIVENESS REDC = INCL. TERMS OF REDUCTION EFRE = INCL. TERMS OF EFFECTIVENESS AND TERMS OF REDUCTION RULE: For MT798<761> this field may only be present if field 22J contains code STND (STANDARD WORDING OF ISSUING BANK)
2.9
22L
Language of Standard Wording
2!c (Code)
DEFN: This field specifies the language of the standard wording of the Issuing Bank, i.e. 2 alphabetic ISO 639 Language Code, e.g. en = English, fr = French, de -= German. RULE: For MT798<761> this field must be present if field 22J contains code STND (STANDARD WORDING OF ISSUING BANK)
2.10
50
Applicant
DEFN: This field specifies the applicant for the guarantee (i.e. the party considered by the issuing bank to be the debtor / obligor).
7 November 2008
169
2.11
50M
Alternative Applicant
DEFN: This field specifies the alternative applicant for the guarantee (i.e. the party to be mentioned in the Guarantee, if different to the Applicant specified in field 50). This field indicates, in case that an Alternative Applicant exists, whether the Applicant is acting on its own behalf or for account of a Third Party. CODES OWNB = ON OWN BEHALF ACTP = FOR ACCOUNT OF THIRD PARTY RULE: For MT798<761> this field must be present if field 50M (Alternative Applicant) is present.
2.12
12E
Indicator of Alternative Beneficial Owner
4!c (Code)
2.13
39P
Guarantee Amount
4!c/3!a15d (Type)(Currency)(Amount)
DEFN: This field specifies the type of guarantee amount, the currency code of the amount and the amount of the guarantee. CODES: PRIN = PRINCIPAL LIABILITY ONLY IINT = INCLUDING INTEREST ICST = INCLUDING COSTS IIAC = INCLUDING INTEREST AND COSTS XINT = PLUS INTEREST XCST = PLUS COSTS XIAC = PLUS INTEREST AND COSTS
2.14
39C
Additional Amounts / Interest Covered
4*35x (Narrative)
DEFN: This field specifies any additional amounts covered by the guarantee in free text form, such as interest and/or costs. RULE: For MT798<761> this field must be present if field 39P contains one of the following codes: XINT, XCST, or XIAC.
170
Trade Standards
2.15
23B
Validity Type
4!c (Type)
DEFN: This field specifies whether the validity of the guarantee is limited or unlimited. CODES: One of the following codes must be used: LIMT = LIMITED UNLM = UNLIMITED
2.16
31L
Validity Expiry Date
6!n (Date)
DEFN: This field specifies the expiry date of the guarantee. RULE: For MT798<761> this field may only be present if field 23B contains code LIMT.
2.17
31S
Approximate Expiry Date
6!n (Date)
DEFN: This field specifies the approximate expiry date of the guarantee (unlimited validity), i.e. the economic maturity as per the underlying transaction. RULE: For MT798<761> this field may only be present if field 23B contains code UNLM.
2.18
35L
Specification of Expiry
4*35x (Narrative)
DEFN: This field specifies the expiry of the guarantee in free text form, in cases that the expiry cannot be expressed as a date, e.g. 180 days after issuance of guarantee. DEFN: This field specifies the method by which the guarantee is to be transmitted to the Advising Bank, if applicable. It could also specify the method by which the request to issue a guarantee is transmitted to the Issuing Bank. CODES: TELE = BY TELECOMMUNICATION COUR = BY COURIER RULE: For MT798<761> additional information may only be used when the method is COUR to optionally specify the name of the courier.
2.19
23E
Method of Transmission
4!c[/30x] (Method)(Additional Information)
7 November 2008
171
2.20
24E
Delivery of original guarantee
DEFN: This field specifies the method by which the original guarantee is to be delivered. CODES: COUR = BY COURIER MAIL = BY MAIL REGM = BY REGISTERED MAIL OR AIRMAIL MESS = BY MESSENGER - PICKUP BY CUSTOMER RULE: For MT798<761> additional information may only be used when the method is COUR to optionally specify the name of the courier. RULE: For MT798<761> this field may only specify code MESS if field 22G (Delivery to) contains code APPL (APPLICANT).
2.21
22G
Delivery to
4!c (Code)
DEFN: This field specifies to whom the original of the Guarantee is to be delivered. CODES: BENE = BENEFICIARY APPL = APPLICANT ALTA = ALTERNATIVE APPLICANT SPEC = SPECIFIED ADDRESS
2.22
50B
Delivery Address
DEFN: This field specifies to whom the original of the Guarantee is to be delivered. RULE: For MT798<761> this field may only be used when field 22G is SPEC.
2.23
53C
Liability Account
/34x (Account)
DEFN: This field specifies the number of the liability account nominated by the Applicant. GUID: For MT798<761> for accounts serviced in countries that have implemented IBAN, the IBAN should be used to identify the account.
172
Trade Standards
2.24
25A
Charges Account
/34x (Account)
DEFN: This field specifies the number of account nominated by the Applicant to be used for settlement of charges. GUID: For MT798<761> for accounts serviced in countries that have implemented IBAN, the IBAN should be used to identify the account.
2.25
59
Beneficiary
[/34x]
(Account
4*35x) (Name & Address) 2.26 52a Issuing Bank A [/1!a][/34x] D [/1!a][/34x] 4*35x 2.27 58a Advising Bank A [/1!a][/34x] D [/1!a][/34x] 4*35x (Party Identifier) (Party Identifier) (Name & Address) (Party Identifier) (Party Identifier) (Name & Address) O O
DEFN: This field specifies the party in favour of which the guarantee is being issued. GUID: For MT798<761>, subfield account is not used. DEFN: This field specifies the issuing bank. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 of the issuing bank. RULE: For MT798<761>, this field may only be used when field 22E consists of INDC (INDIRECT). DEFN: This field specifies the advising bank. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank. RULE: For MT798<761>, this field may only be used when field 22E consists of DIRC (DIRECT).
2.28
49
7!x (Instruction)
DEFN: This field indicates whether the Advising Bank is requested to add its confirmation to the advice of the guarantee. CODES: CONFIRM | WITHOUT. RULE: For MT798<761> this field must be present if field 58a (Advising Bank) is present.
2.29
26D
Liability Details
30*65x (Narrative)
DEFN: This field specifies a brief description of the guaranteed liability.
7 November 2008
173
2.30
20E
Reference
4!c//35x (Code)(Reference)
DEFN: This field defines a reference associated with the guarantee. CODES: TEND = TENDER ORDR = ORDER CONT = CONTRACT OFFR = OFFER DELV = DELIVERY PINV = PROFORMA INVOICE PROJ = PROJECT
2.31
31R
Reference Date
6!n[/6!n] (Date 1)(Date 2)
DEFN: This field specifies the date of the reference, and optionally a secondary date. RULE: For MT798<761> subfield Date2 may only be used when field 20E consists of TEND (tender) to specify the tender closing date.
2.32
71F
Total Order/Contract Amount
DEFN: This field specifies the currency and total amount of the order/contract. RULE: For MT798<761> the currency must be the same currency as in field 39P (Guarantee Amount).
2.33 2.34
37J 29A
Guarantee Value in Percent Customer Contact
12d 4*35x (Narrative)
O O
DEFN: This field specifies the guarantee value in percent in relation to the total order or contract value. DEFN: This field specifies the contact details of the corporate. DEFN: This field specifies the contact details of the beneficiary. DEFN: This field contains additional information for the Receiver.
2.35
29B
Beneficiary Contact
4*35x (Narrative)
2.36
72C
6*35x (Narrative)
174
Trade Standards
MT 798<784> - Request for Standby LC Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<784> The message index number must have a fixed value of 1, e.g. 1/3 or 1/4 or 1/5 depending on the number of 760s.
7 November 2008
175
2.2 2.3
21A 13E
Customer Reference Number Message Creation Date Time Form of Credit
16x 8!n4!n (Date)(Time) 24x (Type)
M M
DEFN: This field specifies the reference number which has been assigned by the customer. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the type of standby letter of credit. CODES: IRREVOCABLE STANDBY = Standby letter of credit is irrevocable. IRREVOC TRANS STANDBY = Standby letter of credit is irrevocable and transferable
2.4
40A
2.5
50
Applicant
DEFN: This is the party on whose behalf the standby letter is issued. DEFN: This field specifies the party who is ultimately obligated under the standby letter of credit, if different from the Applicant. DEFN: This field specifies the currency code of the amount and the amount of the standby letter of credit. DEFN: This field specifies the tolerance relative to the standby letter of credit amount as a percentage plus (Tolerance 1) and/or minus (Tolerance 2) that amount. RULE: MT798<784>, if field 39A is used, field 39B must not be used.
2.6
50M
Ultimate Obligor
2.7
33E
Credit Amount
2.8
39A
2.9
39B
13x
DEFN: This field further qualifies the standby letter of credit amount. CODES: NOT EXCEEDING RULE: MT798<784>, if field 39B is used, field 39A must not be used.
2.10
31L
6!n (Date)
DEFN: This field specifies the expiry date of the standby letter of credit.
176
Trade Standards
2.11
35L
4*35x (Narrative)
DEFN: This field specifies the expiry of the standby letter of credit in free text form, in cases that the expiry cannot be expressed as a date, e.g. 180 days after issuance of a standby letter of credit. DEFN: This field specifies the requirement for a clause covering an automatic extension of the validity expiry date: CODES: ONEY = ONE YEAR EXTENSION CLAUSE OTHR = OTHER EXTENSION PERIOD CLAUSE RULE: For MT798<784> additional information may only be used when the code is OTHR to specify the extension period.
2.12
23F
Automatic Extension Period
4!c[/30x] (Code)(Additional Information)
2.13
38A
Automatic Extension End Notice Days
3n (Days)
DEFN: This field specifies the minimum number of calendar days for notice on non-extension to the beneficiary. RULE: For MT798<784> this field may only be present if field 23F contains code ONEY or OTHR.
2.14
31S
Automatic Extension Final Expiry Date
6!n (Date)
DEFN: This field specifies the date after which the credit will no longer be subject to automatic extension. RULE: For MT798<784> this field may only be present if field 23F contains code ONEY or OTHR.
2.15
23E
DEFN: This field specifies the method by which the standby letter of credit is to be transmitted to the Advising Bank. CODES: TELE = BY TELECOMMUNICATION COUR = BY COURIER MAIL = AIR MAIL RULE: For MT798<784> additional information may only be used when the method is COUR to optionally specify the name of the courier.
7 November 2008
177
2.16
24E
Delivery of Original Credit
DEFN: This field specifies the method by which the original standby letter of credit is to be delivered. CODES: COUR = BY COURIER MAIL = BY MAIL REGM = BY REGISTERED MAIL OR AIRMAIL MESS = BY MESSENGER - PICKUP BY CUSTOMER RULE: For MT798<784> additional information may only be used when the method is COUR to optionally specify the name of the courier. RULE: For MT798<784> this field may only specify code MESS if field 22G (Delivery to) contains code APPL (APPLICANT) or BENE (BENEFICIARY).
2.17
22G
Delivery to
4!c (Code)
DEFN: This field specifies to whom the original of the standby letter of credit is to be delivered. CODES: BENE = BENEFICIARY APPL = APPLICANT OBLG = ULTIMATE OBLIGOR SPEC = SPECIFIED ADDRESS RULE: For MT798<784> this field may only specify code OBLIG if field 50M (Ultimate Obligor) has been specified.
2.18
50B
Delivery Address
DEFN: This field specifies to whom the original of the Standby letter of credit is to be delivered. RULE: For MT798<784> this field may only be used when field 22G (Delivery to) is SPEC.
2.19
25A
Charges Account
/34x (Account)
DEFN: This field specifies the number of account nominated by the applicant to be used for settlement of charges. GUID: For MT798<784> for accounts serviced in countries that have implemented IBAN, the IBAN should be used to identify the account.
178
Trade Standards
2.20
22P
Drawing Mode
4!c[/4!c] (Code)(Code)
DEFN: This field specifies if multiple drawings are allowed against the standby letter of credit CODES (subfield 1): MULT = MULTIPLE DRAWINGS ALLOWED CODES (subfield 2): PART = PARTIAL DRAWINGS ALLOWED NOTE: Partial drawings can only be allowed when multiple drawings are allowed.
2.21
45C
Drawing Requirements
100*65x (Narrative)
DEFN: This field specifies the documents and/or instructions under which the payment will be made available to the beneficiary. DEFN: This field specifies the party in favour of which the standby letter of credit is being issued. GUID: For MT798<784>, subfield account is not used.
2.22
59
Beneficiary
[/34x] 4*35x)
(Account (Name & Address
2.23
29B
Beneficiary Contact
4*35x (Narrative)
DEFN: This field specifies the contact details of the beneficiary. DEFN: This field specifies the party in favour of which a guarantee or undertaking is issued by the beneficiarys bank or correspondent based on the standby letter of credit. DEFN: This field specifies the contact name for the party in favour of which a guarantee or undertaking is issued by the beneficiarys bank or correspondent based on the standby letter of credit. RULE: For MT798<784> this field may be present if field 50N (Secondary Credit Beneficiary) is present.
2.24
50N
Secondary Credit Beneficiary
2.25
29C
Secondary Credit Contact Name
35x
7 November 2008
179
2.26
22K
Secondary Credit Type
DEFN: This field specifies the type of the bond, guarantee or undertaking for a secondary credit. CODES: BIDB = BID BOND PERB = PERFORAMNCE BOND GUAR = GUARANTEE UNDT = UNDERTAKING OTHR = any other type, which must be specified in narrative (2nd subfield) RULE: For MT798<784> narrative may only be used in combination with 'OTHR' to specify in free text form the secondary credit type. RULE: For MT798<784> this field may be present if field 50N (Secondary Credit Beneficiary) is present.
2.27
33F
Secondary Credit Amount
DEFN: This field specifies the currency code of the amount and the amount of the standby letter of credit. RULE: For MT798<784> this field may be present if field 50N (Secondary Credit Beneficiary) is present.
2.28
31V
Secondary Credit Validity Expiry Date
6!n (Date)
DEFN: This field specifies the expiry date of the secondary standby letter of credit. RULE: For MT798<784> this field may be present if field 50N (Secondary Credit Beneficiary) is present.
2.29
52a
Issuing Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
(Party Identifier) (Party Identifier) (Name & Address) (Party Identifier) (Party Identifier) (Name & Address)
DEFN: This field specifies the issuing bank. RULE: MT798<784> When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 of the issuing bank.
2.30
58a
Advising Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the advising bank. RULE: MT798<784> When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank.
180
Trade Standards
2.31
49
7!x (Instruction)
DEFN: This field indicates whether the Advising Bank is requested to add its confirmation to the advice of the standby letter of credit. CODES: CONFIRM = The Advising Bank is requested to confirm the credit. MAY ADD = The Advising Bank may add its confirmation to the credit. WITHOUT = The Advising Bank is not requested to confirm the credit.
2.32
26D
Credit Purpose
30*65x (Narrative)
DEFN: This field describes the purpose of the standby letter of credit. DEFN: This field specifies the contact details of the corporate. DEFN: This field contains additional information for the Receiver.
2.33
29A
Customer Contact
4*35x (Narrative)
2.34
72C
6*35x (Narrative)
MT 798<760> Application for issuance of Guarantee / Standby LC Details

Section 1 - MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<760> this field should be assigned a value by the corporate, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the corporate. 1.2 12 Sub-Message Type 3!n M DEFN: This field is used to specify the sub-message type number to allow a specific sub-message to be identified within the MT798, e.g. 770 (LC Application Index), 700 (LC Application Details), 701 (LC Application Extension). RULE: For MT798<760> the sub-message type must have a fixed value of 760.
7 November 2008
181
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT760] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: MT798<760> The message index number must start with a value of 2 for the first MT798<760> in the series and be incremented by 1 for each subsequent MT798<760>, e.g. 2/4, 3/4, 4/4. NOTE: This field is not present in the MT760 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer.. NOTE: This field is not present in the MT760 Message Reference Guide. 2.3 27 Sequence of Total 1!n/1!n (Number)(Total) M DEFN: This field specifies the number of this message in the series of messages sent for a guarantee, and the total number of messages in the series RULE: For MT798<760> this field is not validated by the bank. 2.4 20 Transaction Reference Number 16x M DEFN: This field contains a reference assigned by the Sender to unambiguously identify the message. RULE: For MT798<760> this field must specify a guarantee / standby letter of credit number, preassigned by the bank, or a fixed value of NONREF
182
Trade Standards
2.5
23
Further Identification
16x (Code)
DEFN: This field further identifies the purpose of the message. CODES: ISSUE | REQUEST RULE: For MT798<760>, field must consist of ISSUE when field 22E of MT798<761> consists of DIRC (DIRECT). RULE: For MT798<760>, field must consist of REQUEST when field 22E of MT798<761> consists of INDC (INDIRECT) or when MT798<760> is for a standby letter of credit.
2.6
30
Date
6!n (Date)
DEFN: When the message is sent to issue a guarantee, this field specifies the issue date of the guarantee. When the message is sent to request the Receiver to issue a guarantee, this field specifies the date of the request. RULE: For MT798<760> this field is not used
2.7
40C
Applicable Rules
4!a[/35x] (Type)(Narrative)
DEFN: This field specifies the rules the guarantee is subject to. Unless otherwise specified, it is also the rules the counter-guarantee is subject to. CODES: ISPR | NONE | OTHR | URDG
2.8
77C
Details of Guarantee
150*65x (Narrative)
DEFN: This field contains all terms, conditions and details of the guarantee. RULE: For MT798<760>, field only used when field 22J of MT798<761> consists of WDAP (wording drafted by applicant) or WDBF (wording drafted by beneficiary). GUID: Information specified in MT798<761> or MT798<784> should not be replicated in this field.
2.9
72
6*35x (Narrative)
DEFN: This field contains additional information for the Receiver. RULE: For MT798<760> this field is not used
7 November 2008
183
Business Example
Please note that for the following example, the assumption is that appropriate agreements have been put in place between the different customer parties and the receiving banks to execute the application requested.
Narrative
Pumpen AG, Postfach 123, 60599 Frankfurt, GERMANY has signed a contract with Mining Ltd., Main Road, Oslo, NORWAY regarding the delivery of pumps and equipment. The contract is comprised of the following: Contract Number: ABC123 Contract Date: 05th February 2008 Total Contract Amount: EUR 500.000,00 It has been agreed between the Buyer and the Seller, that the Seller needs to provide a standard Performance Guarantee for 10 % of the total contract value valid until the 31st December 2008. On 05th May 2008 Pumpen AG instructs its bank, i.e. Bank of Germany AG in Frankfurt to issue a standard Performance Guarantee in English in favour of the buyer. The guarantee should be delivered to the Beneficiary by registered mail or airmail. The sellers contact is John Sixpack and the reference number for this transaction is XYZ999
Information Flow
SWIFT Messages SWIFT Message 1 MT798 <761> Explanation Sender Message Type Receiver Message Text Format PUMPCORP 798 BOGEDEFFXXX
184
Trade Standards
Transaction reference number Sub-message type Proprietary message
:20:FGH96372 :12:761 :77E: :27A:1/2 :21A:XYZ999 :13E:200805051433 :22D:GUAR :22K:PGCO :22E:DIRC :22J:STND :22L:en :50:Pumpen AG Postfach 123 60599 Frankfurt / GERMANY :39P:PRIN/EUR50000, :23B:LIMT :31L:081231 :24E:REGM :22G:BENE :59:Mining Ltd. Main Road Oslo / NORWAY :26D:pumps and equipment :20E:CONT//ABC123 :31R:080205 :71F:EUR50000, :37J:10, :29A: John Sixpack
SWIFT Message - 2 MT798 <760> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type :20:FGH96372 :12:760 Format PUMPCORP 798 BOGEDEFFXXX
7 November 2008
185
Proprietary message
:77E: :27A:2/2 :21A:XYZ999 :27:1/1 :20:NONREF :23:ISSUE :40C:NONE :77C:STANDARD WORDING
5.3.2
Scope
Notification of Guarantee / Standby Letter of Credit

The Notification of the Issue of or the Request to a third bank for issuance of, a Guarantee / Standby Letter of Credit is sent to the corporate by its bank and comprises at least two MT798 (Proprietary) messages. It may be used in the following scenarios:

Usage
To notify the applicant that a Guarantee / Standby Letter of Credit has been issued To notify the applicant that a request to a third bank for the issuance of a Guarantee / Standby Letter of Credit has been initiated
A single Notification of Guarantee / Standby Letter of Credit must comprise:
The first MT798 message identified with a sub-message type of 762 in the case of a guarantee or a sub-message type of 785 in the case of a standby letter of credit, and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT760 message, specific to the corporate-to-bank exchange. The second MT798 message identified with a sub-message type of 760 and enveloping one MT760 message. The existing bank-to-bank MT760 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
Each MT798 message for a single Notification of Guarantee / Standby Letter of Credit must be identified with the Customer Number, specified as field 21A, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD.
186
Trade Standards
MT 798<762> - Notification of Guarantee Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<762> The message index number must have a fixed value of 1, e.g. 1/3
7 November 2008
187
2.2
21A
Customer Reference Number Guarantee Number Message Creation Date Time Guarantee Amount
16x
DEFN: This field is used to specify the request reference number as assigned by the corporate in the initiating request. DEFN: This field specifies the reference number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the type of guarantee amount, the currency code of the amount and the amount of the guarantee. CODES: PRIN = PRINCIPAL LIABILITY ONLY IINT = INCLUDING INTEREST ICST = INCLUDING COSTS IIAC = INCLUDING INTEREST AND COSTS XINT = PLUS INTEREST XCST = PLUS COSTS XIAC = PLUS INTEREST AND COSTS
2.3 2.4
20 13E
16x 8!n4!n (Date)(Time) 4!c/3!a15d (Type)(Currency)(Amount)
M M
2.5
39P
2.6
23B
Validity Type
4!c (Type)
DEFN: This field specifies whether the validity of the guarantee is limited or unlimited. CODES: One of the following codes must be used: LIMT = LIMITED UNLM = UNLIMITED
2.7
31L
6!n (Date)
DEFN: This field specifies the expiry date of the guarantee. RULE: For MT798<762> this field may only be present if field 23B contains code LIMT.
2.8
31S
Approximate Expiry Date
6!n (Date)
DEFN: This field specifies the approximate expiry date of the guarantee (unlimited validity), i.e. the economic maturity as per the underlying transaction. RULE: For MT798<762> this field may only be present if field 23B contains code UNLM.
188
Trade Standards
2.9
50
Applicant
DEFN: This field specifies the applicant for the guarantee (i.e. the party considered by the issuing bank to be the debtor / obligor). DEFN: This field specifies the alternative applicant for the guarantee (i.e. the party to be mentioned in the Guarantee, if different to the Applicant specified in field 50). DEFN: This field specifies the party in favour of which the guarantee is being issued. GUID: For MT798<762>, subfield account is not used.
2.10
50M
Alternative Applicant
2.11
59
Beneficiary
[/34x] 4*35x)
(Account (Name & Address) (Party Identifier) (Party Identifier) (Name & Address) (Party Identifier) (Party Identifier) (Name & Address)
2.12
52a
Issuing Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the issuing bank. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 of the issuing bank.
2.13
58a
Advising Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the advising bank. RULE: When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank.
2.14
49H
Special agreements
50*65x (Narrative)
DEFN: This field indicates any special agreements between the Customer and the bank for the specified guarantee. DEFN: This field specifies the contact details of the bank DEFN: This field contains additional information for the Receiver.
2.15
29B
Bank Contact
4*35x (Narrative)
2.16
72C
6*35x (Narrative)
7 November 2008
189
MT 798<785> - Notification of Standby LC Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<785> The message index number must have a fixed value of 1, e.g. 1/3
190
Trade Standards
2.2
21A
Customer Reference Number Credit Number Message Creation Date Time Form of Credit
16x
DEFN: This field is used to specify the request reference number as assigned by the corporate in the initiating request. DEFN: This field specifies the reference number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the type of standby letter of credit. CODES: IRREVOCABLE STANDBY = Standby letter of credit is irrevocable. IRREVOC TRANS STANDBY = Standby letter of credit is irrevocable and transferable
2.3 2.4
20 13E
16x 8!n4!n (Date)(Time) 24x (Type)
M M
2.5
40A
2.6
50
Applicant
DEFN: This is the party on whose behalf the standby letter is issued. DEFN: This field specifies the party who is ultimately obligated under the standby letter of credit, if different from the Applicant. DEFN: This field specifies the currency code of the amount and the amount of the standby letter of credit. DEFN: This field specifies the tolerance relative to the standby letter of credit amount as a percentage plus (Tolerance 1) and/or minus (Tolerance 2) that amount. RULE: MT798<785>, if field 39A is used, field 39B must not be used.
2.7
50M
Ultimate Obligor
2.8
33E
Credit Amount
2.9
39A
2.10
39B
13x
DEFN: This field further qualifies the standby letter of credit amount. CODES: NOT EXCEEDING RULE: MT798<785>, if field 39B is used, field 39A must not be used.
7 November 2008
191
2.11
31L
6!n (Date)
DEFN: This field specifies the expiry date of the standby letter of credit. DEFN: This field specifies the expiry of the standby letter of credit in free text form, in cases that the expiry cannot be expressed as a date, e.g. 180 days after issuance of a standby letter of credit. DEFN: This field specifies the requirement for a clause covering an automatic extension of the validity expiry date: CODES: ONEY = ONE YEAR EXTENSION CLAUSE OTHR = OTHER EXTENSION PERIOD CLAUSE RULE: For MT798<785> additional information may only be used when the code is OTHR to specify the extension period.
2.12
35L
4*35x (Narrative)
2.13
23F
Automatic Extension Period
2.14
38A
Automatic Extension End Notice Days
3n (Days)
DEFN: This field specifies the minimum number of calendar days for notice on non-extension to the beneficiary. RULE: For MT798<785> this field may only be present if field 23F contains code ONEY or OTHR.
2.15
31S
Automatic Extension Final Expiry Date
6!n (Date)
DEFN: This field specifies the date after which the credit will no longer be subject to automatic extension. RULE: For MT798<785> this field may only be present if field 23F contains code ONEY or OTHR.
2.16
23E
DEFN: This field specifies the method by which the standby letter of credit is to be transmitted to the Advising Bank. CODES: TELE = BY TELECOMMUNICATION COUR = BY COURIER MAIL = AIR MAIL RULE: For MT798<785> additional information may only be used when the method is COUR to optionally specify the name of the courier.
192
Trade Standards
2.17
24E
Delivery of Original Credit
DEFN: This field specifies the method by which the original standby letter of credit is to be delivered. CODES: COUR = BY COURIER MAIL = BY MAIL REGM = BY REGISTERED MAIL OR AIRMAIL MESS = BY MESSENGER - PICKUP BY CUSTOMER RULE: For MT798<785> additional information may only be used when the method is COUR to optionally specify the name of the courier. RULE: For MT798<785> this field may only specify code MESS if field 22G (Delivery to) contains code APPL (APPLICANT) or BENE (BENEFICIARY).
2.18
22G
Delivery to
4!c (Code)
DEFN: This field specifies to whom the original of the standby letter of credit is to be delivered. CODES: BENE = BENEFICIARY APPL = APPLICANT OBLG = ULTIMATE OBLIGOR SPEC = SPECIFIED ADDRESS RULE: For MT798<785> this field may only specify code OBLIG if field 50M (Ultimate Obligor) has been specified.
2.19
50B
Delivery Address
DEFN: This field specifies to whom the original of the Standby letter of credit is to be delivered. RULE: For MT798<785> this field may only be used when field 22G (Delivery to) is SPEC.
2.20
25A
Charges Account
/34x (Account)
DEFN: This field specifies the number of account nominated by the applicant to be used for settlement of charges. GUID: For MT798<785> for accounts serviced in countries that have implemented IBAN, the IBAN should be used to identify the account.
7 November 2008
193
2.21
22P
Drawing Mode
4!c[/4!c] (Code)(Code)
DEFN: This field specifies if multiple drawings are allowed against the standby letter of credit CODES (subfield 1): MULT = MULTIPLE DRAWINGS ALLOWED CODES (subfield 2): PART = PARTIAL DRAWINGS ALLOWED NOTE: Partial drawings can only be allowed when multiple drawings are allowed.
2.22
45C
Drawing Requirements
100*65x (Narrative)
DEFN: This field specifies the documents and/or instructions under which the payment will be made available to the beneficiary. DEFN: This field specifies the party in favour of which the standby letter of credit is being issued. GUID: For MT798<785>, subfield account is not used.
2.23
59
Beneficiary
[/34x] 4*35x)
(Account (Name & Address)
2.24
29B
Beneficiary Contact
4*35x (Narrative)
DEFN: This field specifies the contact details of the beneficiary. DEFN: This field specifies the party in favour of which a guarantee or undertaking is issued by the beneficiarys bank or correspondent based on the standby letter of credit. DEFN: This field specifies the contact name for the party in favour of which a guarantee or undertaking is issued by the beneficiarys bank or correspondent based on the standby letter of credit. RULE: For MT798<785> this field may be present if field 50N (Secondary Credit Beneficiary) is present.
2.25
50N
Secondary Credit Beneficiary
2.26
29C
Secondary Credit Contact Name
35x
194
Trade Standards
2.27
22K
Secondary Credit Type
DEFN: This field specifies the type of the bond, guarantee or undertaking for a secondary credit. CODES: BIDB = BID BOND PERB = PERFORAMNCE BOND GUAR = GUARANTEE UNDT = UNDERTAKING OTHR = any other type, which must be specified in narrative (2nd subfield) RULE: For MT798<785> narrative may only be used in combination with 'OTHR' to specify in free text form the secondary credit type. RULE: For MT798<785> this field may be present if field 50N (Secondary Credit Beneficiary) is present.
2.28
33F
Secondary Credit Amount
DEFN: This field specifies the currency code of the amount and the amount of the standby letter of credit. RULE: For MT798<785> this field may be present if field 50N (Secondary Credit Beneficiary) is present.
2.29
31V
Secondary Credit Validity Expiry Date
6!n (Date)
DEFN: This field specifies the expiry date of the secondary standby letter of credit. RULE: For MT798<785> this field may be present if field 50N (Secondary Credit Beneficiary) is present.
2.30
52a
Issuing Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
(Party Identifier) (Party Identifier) (Name & Address) (Party Identifier) (Party Identifier) (Name & Address)
DEFN: This field specifies the issuing bank. RULE: MT798<785> When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 of the issuing bank.
2.31
58a
Advising Bank
A [/1!a][/34x] D [/1!a][/34x] 4*35x
DEFN: This field specifies the advising bank. RULE: MT798<785> When specified in option A, the identifier code must be the SWIFT BIC8 or BIC11 for the advising bank.
7 November 2008
195
2.32
49
7!x (Instruction)
DEFN: This field indicates whether the Advising Bank is requested to add its confirmation to the advice of the standby letter of credit. CODES: CONFIRM = The Advising Bank is requested to confirm the credit. MAY ADD = The Advising Bank may add its confirmation to the credit. WITHOUT = The Advising Bank is not requested to confirm the credit.
2.33
26D
Credit Purpose
30*65x (Narrative)
DEFN: This field describes the purpose of the standby letter of credit. DEFN: This field specifies the contact details of the bank DEFN: This field contains additional information for the Receiver.
2.34
29B
Bank Contact
4*35x (Narrative)
2.35
72C
6*35x (Narrative)
MT 798<760> - Notification of Guarantee / Standby LC Details

196
Trade Standards
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT760] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: MT798<760> The message index number must start with a value of 2 for the first MT798<760> in the series and be incremented by 1 for each subsequent MT798<760>, e.g. 2/3. NOTE: This field is not present in the MT760 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer. NOTE: This field is not present in the MT760 Message Reference Guide. 2.3 MT760 Message M MT760 message contents.
7 November 2008
197
Business Example
Please note that for the following example, the assumption is that appropriate agreements have been put in place between the different customer parties and the receiving banks to execute the application requested.
Narrative
On 06th May 2008 Bank of Germany AG in Frankfurt issues its Performance Guarantee number PGFFA0815 based on the previously given instructions by Pumpen AG, Postfach 123, 60599 Frankfurt, GERMANY and in favour of Mining Ltd., Main Road, Oslo, NORWAY with the following details: Performance Guarantee No . PGFFA0815 We have been informed that you, Mining PLC, Main Road, Oslo NORWAY, hereinafter called the BUYER have concluded the contract No. ABC123 of 05th February 2008, hereinafter called the CONTRACT, with Pumpen AG, Postfach 123, 60599 Frankfurt, GERMANY, hereinafter called the SELLER, according to which the SELLER will deliver to the BUYER pumps and equipment, in the total value of EUR 500.000,00. As agreed the SELLER has to provide a bank guarantee in favour of the BUYER, amounting to 10 percent of the total value, i.e. EUR 50.000,00 , to cover the fulfilment of the SELLERs obligations under the CONTRACT. In consideration of the aforesaid, we, Bank of Germany Aktiengesellschaft, Frankfurt, Germany, hereby issue the guarantee on behalf of the SELLER towards the BUYER to the maximum amount of EUR 50.000,00 (in words: EUR fifty thousand 00/100) and undertake irrevocably without consideration of any objections and defences of the SELLER or third parties and irrespective of the validity and legal effect of the CONTRACT and waiving any objections arising there from to pay to the BUYER any amount claimed from us by the BUYER up to the maximum amount of this guarantee upon receipt of the BUYER's first demand in writing, in which the BUYER simultaneously confirms that the SELLER is in breach of its obligations towards the BUYER under the CONTRACT. The obligation under this guarantee shall expire on 31st December 2008. Any claim for payment complying with the above conditions must be received by us within the validity period of this guarantee. This guarantee shall be governed by the law of the Federal Republic of Germany. Exclusive place of jurisdiction shall be Frankfurt (Main) GERMANY. On the same day Bank of Germany notifies the Applicant (i.e. Pumpen AG) about the issuance of the guarantee. Bank of Germanys contact is Arthur Dent.
198
Trade Standards
Information Flow
SWIFT Messages SWIFT Message 1 MT798 <762> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type Proprietary message :20:BVC96372 :12:762 :77E: :27A:1/2 :21A:XYZ999 :20:PGFFA0815 :13E:200805061033 :39P:PRIN/EUR50000, :23B:LIMT :31L:081231 :50:Pumpen AG Postfach 123 60599 Frankfurt / GERMANY :59:Mining Ltd. Main Road Oslo / NORWAY :29B: Arthur Dent Format BOGEDEFFXXX 798 PUMPCORP
7 November 2008
199
SWIFT Message - 2 MT798 <760> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type :20:BVC96372 :12:760 Format BOGEDEFFXXX 798 PUMPCORP
200
Trade Standards
Proprietary message
:77E: :27A:2/2 :21A:XYZ999 :27:1/1 :20:PGFFA0815 :23:ISSUE :40C:NONE :77C: Performance Guarantee No . PGFFA0815 We have been informed that you, Mining PLC, Main Road, Oslo NORWAY, hereinafter called the BUYER have concluded the contract No. ABC123 of 05th February 2008, hereinafter called the CONTRACT, with Pumpen AG, Postfach 123, 60599 Frankfurt, GERMANY, hereinafter called the SELLER, according to which the SELLER will deliver to the BUYER pumps and equipment, in the total value of EUR 500.000,00. As agreed the SELLER has to provide a bank guarantee in favour of the BUYER, amounting to 10 percent of the total value, i.e. EUR 50.000,00 , to cover the fulfilment of the SELLERs obligations under the CONTRACT. In consideration of the aforesaid, we, Bank of Germany Aktiengesellschaft, Frankfurt, Germany, hereby issue the guarantee on behalf of the SELLER towards the BUYER to the maximum amount of EUR 50.000,00 (in words: EUR fifty thousand 00/100) and undertake irrevocably without consideration of any objections and defences of the SELLER or third parties and irrespective of the validity and legal effect of the CONTRACT and waiving any objections arising there from to pay to the BUYER any amount claimed from us by the BUYER up to the maximum amount of this guarantee upon receipt of the BUYER's first demand in writing, in which the BUYER simultaneously confirms that the SELLER is in breach of its obligations towards the BUYER under the CONTRACT. The obligation under this guarantee shall expire on 31st December 2008. Any claim for payment complying with the above conditions must be received by us within the validity period of this guarantee. This guarantee shall be governed by the law of the Federal Republic of Germany. Exclusive place of jurisdiction shall be Frankfurt (Main) GERMANY.
7 November 2008
201
5.3.3
Scope
Request for Amendment of Guarantee / Standby Letter of Credit

The Request for Amendment of Guarantee / Standby Letter of Credit is sent by the corporate to its bank and comprises at least two MT798 (Proprietary) messages. For a direct guarantee, these messages are used to request the bank to issue an amendment to a SURETY, a SURETY ON FIRST DEMAND, or a GUARANTEE previously issued on behalf of the Applicant. For an indirect guarantee it could also be used to instruct the bank to issue a request to a Corresponding Bank to issue an amendment to a previously issued guarantee in return for its counter-liability and counter-guarantee. For a standby letter of credit, these messages are used to request the bank to issue an amendment to a STANDBY LETTER OF CREDIT previously issued on behalf of the Applicant.
Usage
A single Request for Amendment Guarantee / Standby Letter of Credit must comprise:
The first MT798 message identified with a sub-message type of 763 in the case of a guarantee or a sub-message type of 786 in the case of a standby letter of credit, and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT767 message, specific to the corporate-to-bank exchange. The second MT798 message identified with a sub-message type of 767 and enveloping one MT767 message. The existing bank-to-bank MT767message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
Each MT798 message for a single Guarantee / Standby Letter of Credit must be identified with the same Customer Reference Number, specified as field 21A, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD.
202
Trade Standards
MT 798<763> - Request for Amendment of Guarantee Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<763> The message index number must have a fixed value of 1, e.g. 1/3. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer.
7 November 2008
203
2.3 2.4
20 13E
Guarantee Number Message Creation Date Time Increase of Guarantee Amount
16x 8!n4!n (Date)(Time) 3!a15d (Currency)(Amount)
M M
DEFN: This field specifies the reference number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field contains the currency and amount of an increase in the Guarantee amount. RULE: For MT798<763>, the currency of the amount must be in the same currency as the original guarantee amount. RULE: For MT798<763>, Either field 32B or field 33B (Decrease of Guarantee Amount) may be present, but not both fields.
2.5
32B
2.6
33B
Decrease of Guarantee Amount
DEFN: This field contains the currency code and amount of a decrease in the Guarantee amount. RULE: For MT798<763>, the currency of the amount must be in the same currency as the original guarantee amount. RULE: For MT798<763>, Either field 32B (Increase of Guarantee Amount) or field 33B may be present, but not both fields.
2.7
23B
New Validity Type
4!c (Type)
DEFN: This field specifies whether the amended validity of the guarantee is limited or unlimited. CODES: One of the following codes must be used: LIMT = LIMITED UNLM = UNLIMITED
2.8
31L
New Validity Expiry Date
6!n (Date)
DEFN: This field specifies the new expiry date of the guarantee (limited validity) in case of an amendment. DEFN: This field specifies the new approximate expiry date of the guarantee (unlimited validity) in case of an amendment, i.e. the economic maturity as per the underlying transaction. RULE: For MT798<763> this field may only be present if field 23B contains code UNLM.
2.9
31S
New Approximate Expiry Date
6!n (Date)
204
Trade Standards
2.10
23E
DEFN: This field specifies the method by which the amendment is to be transmitted to the Advising Bank, if applicable. It could also specify the method by which the request to amendment a guarantee is transmitted to the Issuing Bank. CODES: TELE = BY TELECOMMUNICATION COUR = BY COURIER RULE: For MT798<763> additional information may only be used when the method is COUR to optionally specify the name of the courier.
2.11
24D
Delivery of original amendment
DEFN: This field specifies the method by which the original amendment is to be delivered.. CODES: COUR = BY COURIER MAIL = BY MAIL REGM = BY REGISTERED MAIL OR AIRMAIL MESS = BY MESSENGER - PICKUP BY CUSTOMER RULE: For MT798<763> additional information may only be used when the method is COUR to optionally specify the name of the courier. RULE: For MT798<763> this field may only specify code MESS if field 22G (Delivery to) contains code APPL (APPLICANT).
2.12
22G
Delivery to
4!c (Code)
DEFN: This field specifies to whom the original of the Guarantee amendment is to be delivered. CODES: BENE = BENEFICIARY APPL = APPLICANT ALTA = ALTERNATIVE APPLICANT SPEC = SPECIFIED ADDRESS
7 November 2008
205
2.13
50B
Delivery Address
DEFN: This field specifies to whom the original of the Guarantee amendment is to be delivered. RULE: For MT798<763> this field may only be used when field 22G is SPEC.
2.14
29A
Customer Contact
4*35x (Narrative)
DEFN: This field specifies the contact details of the corporate. DEFN: This field contains additional information for the Receiver.
2.15
72C
6*35x (Narrative)
MT 798<786> - Request for Amendment of Standby LC Index

Section 1 - MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<786> this field should be assigned a value by the corporate, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the corporate. 1.2 12 Sub-Message Type 3!n M DEFN: This field is used to specify the sub-message type number to allow a specific sub-message to be identified within the MT798, e.g. 770 (LC Application Index), 700 (LC Application Details), 701 (LC Application Extension). RULE: For MT798<786> the sub-message type must have a fixed value of 786. 1.3 77E Proprietary Message 73x(Text) [n*78x] (Text) M DEFN: This field is used to convey the message contents in a format agreed to by the Sender and the Receiver. RULE: For MT798<786> the contents of this field are specified in Section 2 that follows below.
206
Trade Standards
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<786> The message index number must have a fixed value of 1, e.g. 1/3. 2.2 2.3 2.4 21A 20 13E Customer Reference Number Credit Number Message Creation Date Time Increase of Credit Amount 16x 16x 8!n4!n (Date)(Time) 3!a15d (Currency)(Amount) O M M M DEFN: This field specifies the reference number which has been assigned by the customer. DEFN: This field specifies the reference number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field contains the currency and amount of an increase in the standby letter of credit amount. RULE: For MT798<786>, the currency of the amount must be in the same currency as the original credit amount. RULE: For MT798<786>, Either field 32B or field 33B (Decrease of Credit Amount) may be present, but not both fields. 2.6 33B Decrease of Credit Amount 3!a15d (Currency)(Amount) O DEFN: This field contains the currency code and amount of a decrease in the standby letter of credit amount. RULE: For MT798<786>, the currency of the amount must be in the same currency as the original credit amount. RULE: For MT798<786>, Either field 32B (Increase of Credit Amount) or field 33B may be present, but not both fields. 2.7 39A New Percentage Credit Amount Tolerance 2n/2n (Tolerance 1)(Tolerance 2) O DEFN: This field specifies the new tolerance relative to the standby letter of credit amount as a percentage plus (Tolerance 1) and/or minus (Tolerance 2) that amount.
2.5
32B
7 November 2008
207
2.8
31L
E 6!n (Date)
DEFN: This field specifies the new expiry date of the standby letter of credit in case of an amendment. DEFN: This field specifies the expiry of the standby letter of credit in free text form, in cases that the expiry cannot be expressed as a date, e.g. 180 days after issuance of a standby letter of credit. DEFN: This field specifies the requirement for a clause covering an automatic extension of the validity expiry date: CODES: ONEY = ONE YEAR EXTENSION CLAUSE OTHR = OTHER EXTENSION PERIOD CLAUSE RULE: For MT798<786> additional information may only be used when the code is OTHR to specify the extension period.
2.9
35L
New Specification of Expiry
4*35x (Narrative)
2.10
23F
New Automatic Extension Period
2.11
38A
New Automatic Extension End Notice Days
3n (Days)
DEFN: This field specifies the new minimum number of calendar days for notice on non-extension to the beneficiary. RULE: For MT798<786> this field may only be present if field 23F contains code ONEY or OTHR.
2.12
31S
New Automatic Extension Final Expiry Date
6!n (Date)
DEFN: This field specifies the new date after which the credit will no longer be subject to automatic extension. RULE: For MT798<786> this field may only be present if field 23F contains code ONEY or OTHR.
208
Trade Standards
2.13
23E
DEFN: This field specifies the method by which the amendment is to be transmitted to the Advising Bank, if applicable. It could also specify the method by which the request to amendment a standby letter of credit is transmitted to the Issuing Bank. CODES: TELE = BY TELECOMMUNICATION COUR = BY COURIER MAIL = AIR MAIL RULE: For MT798<786> additional information may only be used when the method is COUR to optionally specify the name of the courier.
2.14
24D
DEFN: This field specifies the method by which the original standby letter of credit amendment is to be delivered. CODES: COUR = BY COURIER MAIL = BY MAIL REGM = BY REGISTERED MAIL OR AIRMAIL MESS = BY MESSENGER - PICKUP BY CUSTOMER RULE: For MT798<786> additional information may only be used when the method is COUR to optionally specify the name of the courier. RULE: For MT798<786> this field may only specify code MESS if field 22G (Delivery to) contains code APPL (APPLICANT) or BENE (BENEFICIARY).
7 November 2008
209
2.15
22G
Delivery to
4!c (Code)
DEFN: This field specifies to whom the original of the standby letter of credit amendment is to be delivered. CODES: BENE = BENEFICIARY APPL = APPLICANT OBLG = ULTIMATE OBLIGOR SPEC = SPECIFIED ADDRESS RULE: For MT798<786> this field may only specify code OBLIG if field 50M (Ultimate Obligor) has been specified in the opening standby letter of credit (MT798<784>).
2.16
50B
Delivery Address
DEFN: This field specifies to whom the original of the Standby letter of credit amendment is to be delivered. RULE: For MT798<786> this field may only be used when field 22G (Delivery to) is SPEC.
2.17
29A
Customer Contact
4*35x (Narrative)
DEFN: This field specifies the contact details of the corporate. DEFN: This field contains additional information for the Receiver.
2.18
72C
6*35x (Narrative)
MT 798<767> - Request for Amendment of Guarantee / Standby LC Details

Section 1 MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<767> this field should be assigned a value by the corporate, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the corporate.
210
Trade Standards
1.2
12
Sub-Message Type
3!n
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT767] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: MT798<767> The message index number must start with a value of 2 for the first MT798<767> in the series and be incremented by 1 for each subsequent MT798<767>, e.g. 2/3. NOTE: This field is not present in the MT767 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer. NOTE: This field is not present in the MT767 Message Reference Guide. 2.3 27 Sequence of Total 1!n/1!n (Number)(Total) M DEFN: This field specifies the number of this message in the series of messages sent for a guarantee, and the total number of messages in the series. RULE: For MT798<767> this field is not validated by the bank.
7 November 2008
211
2.4
20
Transaction Reference Number
16x
DEFN: This field contains a reference assigned by the Sender to unambiguously identify the message. RULE: For MT798<767> this field specifies the guarantee or standby letter of credit number
2.5
21
Related Reference
16x
DEFN: This field will contain a reference which is meaningful to the Receiver, for example, the guarantee number. RULE: For MT798<767> this field has a fixed value of NONREF
2.6
23
Further Identification
16x (Code)
DEFN: This field further identifies the purpose of the message. CODES: ISSUE 1 REQUEST RULE: For MT798<767>, this field must consist of ISSUE in case of a direct guarantee RULE: For MT798<767>, this field must consist of REQUEST in case of an indirect guarantee or when MT798<760> is for a standby letter of credit.
2.7
30
Date
6!n (Date)
DEFN: When the message is sent to amend a guarantee, this field specifies the date of the amendment. When the message is sent to request the Receiver to amend a guarantee, this field specifies the date of the request for the amendment. RULE: For MT798<767> the field is not used
2.8
26E
Number of Amendment
2n (Number)
DEFN: This field specifies the number which identifies this amendment. RULE: For MT798<767> this number starts at 1 and is incremented by 1 for each subsequent amendment to the same guarantee / standby letter of credit. RULE: For MT798<767> the field is not used
212
Trade Standards
2.9
31C
Date of Issue or Request to Issue
6!n (Date)
DEFN: When the message is sent to amend a guarantee, this field must specify the original issue date of the guarantee. When the message is sent to request the Receiver to amend a guarantee, this field must specify the original date of the request to issue the guarantee. RULE: For MT798<767> this field must be the original issue date of the guarantee or standby letter of credit.
2.10
77C
Amendment Details
150*65x (Narrative)
DEFN: This field specifies all amended terms, conditions and details of the guarantee. GUID: information specified in MT798<763> should not be replicated in this field. Indicate OTHER TERMS REMAIN UNCHANGED when all amendment details are specified in MT798<763>.
2.11
72
6*35x (Narrative)
DEFN: This field contains additional information for the Receiver. RULE: For MT798<767> the field is not used
7 November 2008
213
Business Example
Please note that for the following example, the assumption is that appropriate agreements have been put in place between the different customer parties and the receiving banks to execute the amendment requested.
Narrative
On 21st June 2008 Pumpen AG instructs its bank, i.e. Bank of Germany AG in Frankfurt to amend the Performance Guarantee Number PGFFA0815 (Customer Reference XYZ999) as follows: Please extend the guarantee until 30th June 2009. The guarantee amendment should be delivered to the Beneficiary by registered mail or airmail.
Information Flow
SWIFT Messages SWIFT Message 1 MT798 <763> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type :20:TRE96372 :12:763 Format PUMPCORP 798 BOGEDEFFXXX
214
Trade Standards
Proprietary message
:77E: :27A:1/2 :21A:XYZ999 :20:PGFFA0815 :13E:200806211433 :31L:090630 :24E:REGM :22G:BENE
SWIFT Message - 2 MT798 <767> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type Proprietary message :20:TRE96372 :12:767 :77E: :27A:2/2 :21A:XYZ999 :27:1/1 :20:PGFFA0815 :21:NONREF :23:ISSUE :31C:080506 :77C:All other terms and conditions remain unchanged Format PUMPCORP 798 BOGEDEFFXXX
5.3.4
Scope
Notification of Amendment of Guarantee / Standby Letter of Credit

The Notification of the Issue of, or the Request to a third bank of amendment to, a previously issued Guarantee / Standby Letter of Credit is sent to the corporate by their bank and comprises at least two MT798 (Proprietary) messages. It may be used in the following scenarios:

Usage
To notify the applicant that an amendment to a previously issued Guarantee / Standby Letter of Credit To notify the applicant that a request to a third bank for the amendment to a previously issued Guarantee / Standby Letter of Credit
A single Notification of Amendment of Guarantee / Standby Letter of Credit must comprise:
The first MT798 message identified with a sub-message type of 764 in the case of a guarantee or a sub-message type of 787 in the case of a standby letter of credit, and
7 November 2008
215
enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT767 message, specific to the corporate-to-bank exchange.
The second MT798 message identified with a sub-message type of 767 and enveloping one MT767 message. The existing bank-to-bank MT767 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
Each MT798 messages for a single Notification of Amendment of Guarantee / Standby Letter of Credit must be identified with the same Customer Reference Number, specified as field 21A. the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD.
216
Trade Standards
MT 798<764> - Notification of Amendment of Guarantee LC Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<764> The message index number must have a fixed value of 1, e.g. 1/3. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer.
7 November 2008
217
2.3 2.4
20 13E
Guarantee Number Message Creation Date Time Increase of Guarantee Amount
16x 8!n4!n (Date)(Time) 3!a15d (Currency)(Amount)
M M
DEFN: This field specifies the reference number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field contains the currency and amount of an increase in the Guarantee amount. RULE: For MT798<764>, the currency of the amount must be in the same currency as the original guarantee amount. RULE: For MT798<764>, Either field 32B or field 33B (Decrease of Guarantee Amount) may be present, but not both fields. RULE: For MT798<764>, if field 32B used, field 34B must be present.
2.5
32B
2.6
33B
Decrease of Guarantee Amount
DEFN: This field contains the currency code and amount of a decrease in the Guarantee amount. RULE: For MT798<764>, the currency of the amount must be in the same currency as the original guarantee amount. RULE: For MT798<764>, Either field 32B (Increase of Guarantee Amount) or field 33B may be present, but not both fields. RULE: For MT798<764>, if field 33B used, field 34B must be present.
2.7
34B
New Guarantee Amount After Amendment
DEFN: This field contains the currency code and total amount of the Guarantee after the amendment. RULE: For MT798<764>, the currency of the amount must be in the same currency as the original guarantee amount. RULE: For MT798<764>, if field 34B used, field 32B or field 33B must be present.
218
Trade Standards
2.8
23B
New Validity Type
4!c (Type)
DEFN: This field specifies whether the amended validity of the guarantee is limited or unlimited. CODES: One of the following codes must be used: LIMT = LIMITED UNLM = UNLIMITED
2.9
31L
6!n (Date)
DEFN: This field specifies the new expiry date of the guarantee (limited validity) in case of an amendment. DEFN: This field specifies the new approximate expiry date of the guarantee (unlimited validity) in case of an amendment, i.e. the economic maturity as per the underlying transaction. RULE: For MT798<764> this field may only be present if field 23B contains code UNLM.
2.10
31S
New Approximate Expiry Date
6!n (Date)
2.11
49H
Special agreements
50*65x (Narrative)
DEFN: This field indicates any special agreements between the Customer and the bank for the specified guarantee amendment. DEFN: This field specifies the contact details of the bank DEFN: This field contains additional information for the Receiver.
2.12
29B
Bank Contact
4*35x (Narrative)
2.13
72C
6*35x (Narrative)
MT 798<787> - Notification of Amendment of Standby LC Index

Section 1 - MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<787> this field should be assigned a value by the corporate, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the corporate.
7 November 2008
219
1.2
12
Sub-Message Type
3!n
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<787> The message index number must have a fixed value of 1, e.g. 1/3. 2.2 2.3 2.4 21A 20 13E Customer Reference Number Credit Number Message Creation Date Time 16x 16x 8!n4!n (Date)(Time) M M M DEFN: This field specifies the reference number which has been assigned by the customer. DEFN: This field specifies the reference number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM.
220
Trade Standards
2.5
32B
Increase of Credit Amount
DEFN: This field contains the currency and amount of an increase in the standby letter of credit amount. RULE: For MT798<786>, the currency of the amount must be in the same currency as the original credit amount. RULE: For MT798<786>, Either field 32B or field 33B (Decrease of Credit Amount) may be present, but not both fields. RULE: For MT798<786>, if field 32B used, field 34B must be present.
2.6
33B
Decrease of Credit Amount
DEFN: This field contains the currency code and amount of a decrease in the standby letter of credit amount. RULE: For MT798<786>, the currency of the amount must be in the same currency as the original credit amount. RULE: For MT798<786>, Either field 32B (Increase of Credit Amount) or field 33B may be present, but not both fields. RULE: For MT798<786>, if field 33B used, field 34B must be present.
2.7
34B
New Credit Amount After Amendment
DEFN: This field contains the currency code and total amount of the standby letter of credit after the amendment. RULE: For MT798<786>, the currency of the amount must be in the same currency as the original l credit amount. RULE: For MT798<786>, if field 34B used, field 32B or field 33B must be present.
2.8
39A
New Percentage Credit Amount Tolerance
DEFN: This field specifies the new tolerance relative to the standby letter of credit amount as a percentage plus (Tolerance 1) and/or minus (Tolerance 2) that amount. DEFN: This field specifies the new expiry date of the standby letter of credit in case of an amendment.
2.9
31L
E 6!n (Date)
7 November 2008
221
2.10
35L
New Specification of Expiry
4*35x (Narrative)
DEFN: This field specifies the expiry of the standby letter of credit in free text form, in cases that the expiry cannot be expressed as a date, e.g. 180 days after issuance of a standby letter of credit. DEFN: This field specifies the requirement for a clause covering an automatic extension of the validity expiry date: CODES: ONEY = ONE YEAR EXTENSION CLAUSE OTHR = OTHER EXTENSION PERIOD CLAUSE RULE: For MT798<786> additional information may only be used when the code is OTHR to specify the extension period.
2.11
23F
New Automatic Extension Period
2.12
38A
New Automatic Extension End Notice Days
3n (Days)
DEFN: This field specifies the new minimum number of calendar days for notice on non-extension to the beneficiary. RULE: For MT798<786> this field may only be present if field 23F contains code ONEY or OTHR.
2.13
31S
New Automatic Extension Final Expiry Date
6!n (Date)
DEFN: This field specifies the new date after which the credit will no longer be subject to automatic extension. RULE: For MT798<786> this field may only be present if field 23F contains code ONEY or OTHR.
2.14
23E
DEFN: This field specifies the method by which the amendment is to be transmitted to the Advising Bank, if applicable. It could also specify the method by which the request to amendment a standby letter of credit is transmitted to the Issuing Bank. CODES: TELE = BY TELECOMMUNICATION COUR = BY COURIER MAIL = AIR MAIL RULE: For MT798<786> additional information may only be used when the method is COUR to optionally specify the name of the courier.
222
Trade Standards
2.15
24D
DEFN: This field specifies the method by which the original standby letter of credit amendment is to be delivered. CODES: COUR = BY COURIER MAIL = BY MAIL REGM = BY REGISTERED MAIL OR AIRMAIL MESS = BY MESSENGER - PICKUP BY CUSTOMER RULE: For MT798<786> additional information may only be used when the method is COUR to optionally specify the name of the courier. RULE: For MT798<786> this field may only specify code MESS if field 22G (Delivery to) contains code APPL (APPLICANT) or BENE (BENEFICIARY).
2.16
22G
Delivery to
4!c (Code)
DEFN: This field specifies to whom the original of the standby letter of credit amendment is to be delivered. CODES: BENE = BENEFICIARY APPL = APPLICANT OBLG = ULTIMATE OBLIGOR SPEC = SPECIFIED ADDRESS
2.17
50B
Delivery Address
DEFN: This field specifies to whom the original of the standby letter of credit amendment is to be delivered. RULE: For MT798<786> this field may only be used when field 22G (Delivery to) is SPEC.
2.18
29B
Bank Contact
4*35x (Narrative)
DEFN: This field specifies the contact details of the bank DEFN: This field contains additional information for the Receiver.
2.19
72C
6*35x (Narrative)
7 November 2008
223
MT 798<767> - Notification of Amendment of Guarantee / Standby LC Details

[n*78x] (Text)
224
Trade Standards
Section 2 Field 77E Structure [MT767] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: MT798<767> The message index number must start with a value of 2 for the first MT798<767> in the series and be incremented by 1 for each subsequent MT798<767>, e.g. 2/3. NOTE: This field is not present in the MT767 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer. NOTE: This field is not present in the MT767 Message Reference Guide. 2.3 MT767 Message M MT767 message contents.
7 November 2008
225
Business Example
Please note that for the following example, the assumption is that appropriate agreements have been put in place between the different customer parties and the receiving banks to execute the amendment requested.
Narrative
On 22nd June 2008 Bank of Germany AG in Frankfurt issues an amendment to its Performance Guarantee number PGFFA0815 based on the previously given instructions by Pumpen AG with the following details: Re: Our Performance Guarantee No . PGFFA0815 issued on 06th May 2008 for EUR 50.000,00 in favour of Mining PLC, Main Road, Oslo NORWAY, on behalf of Pumpen AG, Postfach 123, 60599 Frankfurt, GERMANY concerning the delivery of pumps and equipment as per contract number ABC123 dated 05th February 2008. Dear Sirs, at the request of our customers, we hereby extend the validity of our above mentioned guarantee as follows: Our liability under this guarantee will expire on 30th June 2009, at the latest, by which date any claim for payment must be received by us. All other terms and conditions remain unchanged. Very truly yours BANK OF GERMANY Aktiengesellschaft On the same day Bank of Germany notifies the Applicant (i.e. Pumpen AG) about the amendment to the guarantee.
Information Flow
SWIFT Messages SWIFT Message 1 MT798 <764> Explanation Sender Format BOGEDEFFXXX
226
Trade Standards
Message Type Receiver Message Text Transaction reference number Sub-message type Proprietary message
798 PUMPCORP
:20:KLM96372 :12:764 :77E: :27A:1/2 :21A:XYZ999 :20:PGFFA0815 :13E:200806221033 :31L:090630:
SWIFT Message - 2 MT798 <767> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type Proprietary message :20:BVC96372 :12:767 :77E: :27A:2/2 :21A:XYZ999 :27:1/1 :20:PGFFA0815 :21:NONREF :23:ISSUE :31C:080506 :77C:All other terms and conditions remain unchanged. Format BOGEDEFFXXX 798 PUMPCORP
5.3.5
Scope
Advice of Reduction or Release

The Advice of Reduction or Release is sent to the corporate by their bank and comprises at least two MT798 (Proprietary) messages. These messages are used to advise the reduction in or release of liability for either a previously issued Guarantee or a previously issued Standby Letter of Credit.
Usage
A single Advice of Reduction or Release must comprise:
The first MT798 message identified with a sub-message type of 766 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT769 message, specific to the corporate-to-bank exchange.
7 November 2008
227
The second MT798 message identified with a sub-message type of 769 and enveloping one MT769 message. The existing bank-to-bank MT769 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
Each MT798 messages for a single Advice of Reduction or Release must be identified with the same Customer Reference Number, specified as field 21A, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters. Dates defined as 6!n must be in the form of YYMMDD. Dates defined as 8!n must be in the form of YYYYMMDD.
228
Trade Standards
MT 798<766> - Advice of Reduction or Release Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<766> The message index number must have a fixed value of 1, i.e. 1/2.
7 November 2008
229
2.2
21A
16x
DEFN: This field specifies the reference number which has been assigned by the customer or a fixed value of NONREF (e.g. in cases where no reference is available). DEFN: This field specifies the reference number which has been assigned by the bank. DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the contact details of the bank DEFN: This field contains additional information for the Receiver.
2.3 2.4
20 13E
Guarantee/Credit Number Message Creation Date Time Bank Contact
16x 8!n4!n (Date)(Time) 4*35x (Narrative)
M M
2.5
29B
2.6
72C
6*35x (Narrative)
MT 798<769> - Advice of Reduction or Release Details

230
Trade Standards
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT769] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: MT798<769> The message index number must have a fixed value of 2, i.e. 2/2. NOTE: This field is not present in the MT769 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer or a fixed value of NONREF (e.g. in cases where no reference is available). NOTE: This field is not present in the MT769 Message Reference Guide. 2. 3 MT769 Message M MT769 message contents. RULE: The following fields in the MT769 message might not be used: Tag 25 32a 57a 71B Field Name Account Identification Amount of Charges Account With Bank Details of Charges
7 November 2008
231
Business Example
Please note that for the following example, the assumption is that appropriate agreements have been put in place between the different customer parties and receiving banks.
Narrative
On 10th July 2008 Bank of Germany AG in Frankfurt informs its customer Pumpen AG that it has been released of all its liability under the Performance Guarantee number PGFFA0815 (customer reference number XYZ999) for an amount of EUR 50.000,00. The outstanding guarantee amount is EUR 0,00.
Information Flow
SWIFT Messages SWIFT Message 1 MT798 <766> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type Proprietary message :20:DAS96372 :12:766 :77E: :27A:1/2 :21A:XYZ999 :20:PGFFA0815 :13E:200807101145 Format BOGEDEFFXXX 798 PUMPCORP
232
Trade Standards
SWIFT Message - 2 MT798 <769> Explanation Sender Message Type Receiver Message Text Transaction reference number Sub-message type Proprietary message :20:DAS96372 :12:769 :77E: :27A:2/2 :21A:XYZ999 :20:PGFFA0815 :21:NONREF :30:080710 :33B:EUR50000, :34B:0, Format BOGEDEFFXXX 798 PUMPCORP
7 November 2008
233
5.4
Free Format Messages

This section covers the Free Format Messages that may be used in a corporate-to-bank and bank-to-corporate environment to send or receive information for which another message type is not applicable.
Free Format Message Corporate-to-Bank Free Format Message Bank-to-Corporate
The following diagram depicts the transaction flows:

MT Message Type SubMessage Type Status Max. Occur Name Base Message Type
Free Format Message C2B MT798 MT798 788 799 M M 1 1 Free Format Message Index Free Format Message Details MT799
Free Format Message B2C MT798 MT798 789 799 M M 1 1 Free Format Message Index Free Format Message Details MT799
234
Trade Standards
Legend Status M O Usage Details DEFN RULE GUID CODE NOTE Format a c n x Mandatory Optional Definition Usage Rule. Must be adhered to Usage Guidance. Recommended practice Applicable Code Values Remark alphabetic, capital letters (A through Z), upper case only alpha-numeric capital letters (upper case), and digits only numeric, digits (0 through 9) only SWIFT X set: ! d A to Z a to z 0 to 9 / - ? : ( ) . , + SPACE CrLf
fixed length decimals, including decimal comma ',' preceding the fractional part. The fractional part may be missing, but the decimal comma must always be present or
Codes
5.4.1
Scope
Free Format Message - Corporate-to-Bank

The Free Format Message is sent by the corporate to its bank and comprises two MT798 (Proprietary) messages. The message may be used to send information for which another message type is not applicable.
Usage
A Free Format Message must comprise:
The first MT798 message identified with a sub-message type of 788 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT799 message, specific to the corporate-to-bank exchange. The second MT798 message identified with a sub-message type of 799 and enveloping one MT799 message. The existing bank-to-bank MT799 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
7 November 2008
235
Each MT798 messages for a single Free Format Message must be identified with the same Customer Reference Number, specified as field 21A, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters.
236
Trade Standards
MT 798<788> - Free Format Message - Corporate-to-Bank Index

[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<788> The message index number must have a fixed value of 1, i.e. 1/2. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer.
7 November 2008
237
2.3
21R
Bank Reference Number
16x
DEFN: This field specifies the reference number of the bank (i.e. Documentary Credit Number or Guarantee Number). DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the contact details of the corporate. DEFN: This field specifies additional information for the recipient.
2.4
13E
Message Creation Date Time Customer Contact
8!n4!n (Date)(Time) 4*35x (Narrative)
2.5
29A
2.6
72C
6*35x (Narrative)
MT 798<799> - Free Format Message - Corporate-to-Bank Details

[n*78x] (Text)
238
Trade Standards
Section 2 Field 77E Structure [MT799] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<799> The message index number must have a fixed value of 1, i.e. 1/2. NOTE: This field is not present in the MT799 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer. NOTE: This field is not present in the MT799 Message Reference Guide. 2.3 20 Transaction Reference Number 16x M DEFN: This field specifies the reference number of the bank (i.e. Documentary Credit Number or Guarantee Number) RULE: For MT798<799> The content of this field must be identical to the content of field 21R of MT798<788>. 2.4 21 Related Reference Number 16x O DEFN: This field contains a reference number to the related message. RULE: For MT798<799> This field is not used. 2.5 79 Narrative 35*50x (Narrative) M DEFN: This field contains the free format message.
7 November 2008
239
5.4.2
Scope
Free Format Message - Bank-to-Corporate

The Free Format Message is sent by the bank to its corporate and comprises two MT798 (Proprietary) messages. The message may be used to send information for which another message type is not applicable.
Usage
A Free Format Message must comprise:
The first MT798 message identified with a sub-message type of 789 and enveloping one proprietary index message. This proprietary message contains additional data not covered in the MT799 message, specific to the corporate-to-bank exchange. The second MT798 message identified with a sub-message type of 799 and enveloping one MT799 message. The existing bank-to-bank MT799 message specification is used, without technical change, but with the implementation governed by a set of additional usage guidelines as detailed in this document. These guidelines may override usage conventions that are specific to bank-to-bank implementation usage and may provide additional usage conventions to enable corporate-to-bank implementation.
Each MT798 messages for a single Free Format Message must be identified with the same Bank Reference Number (i.e. Documentary Credit Number or Guarantee Number), specified as field 21R (Bank Reference Number) in the index message or field 20 (Transaction Reference Number) in the details message, the second field encapsulated by field 77E in the MT798. Each MT798 message must not exceed 10,000 characters, further the size of field 77E (Proprietary Message) must not exceed 9,800 characters.
240
Trade Standards
MT 798<789> - Free Format Message - Bank-to-Corporate Index

Section 1 MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<789> this field should be assigned a value by the corporate, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the corporate. 1.2 12 Sub-Message Type 3!n M DEFN: This field is used to specify the sub-message type number to allow a specific sub-message to be identified within the MT798, e.g. 770 (LC Application Index), 700 (LC Application Details), 701 (LC Application Extension). RULE: For MT798<789> the sub-message type must have a fixed value of 788. 1.3 77E Proprietary Message 73x (Text) M DEFN: This field is used to convey the message contents in a format agreed to by the Sender and the Receiver. RULE: For MT798<789> the contents of this field are specified in Section 2 that follows below.
[n*78x] (Text)
Section 2 Field 77E Structure [Proprietary Message] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<789> The message index number must have a fixed value of 1, i.e. 1/2.
7 November 2008
241
2.2
21A
16x
DEFN: This field specifies the reference number which has been assigned by the customer or a fixed value of NONREF (e.g. in cases where no reference is available). DEFN: This field specifies the reference number of the bank (i.e. Documentary Credit Number or Guarantee Number). DEFN: Date and time at which the message was created. Date format YYYYMMDD. Time format: HHMM. DEFN: This field specifies the contact details of the bank. DEFN: This field specifies additional information for the recipient.
2.3
21R
Bank Reference Number
16x
2.4
13E
Message Creation Date Time Bank Contact
8!n4!n (Date)(Time) 4*35x (Narrative)
2.5
29B
2.6
72C
6*35x (Narrative)
MT 798<799> - Free Format Message - Bank-to-Corporate Details

Section 1 MT798 Structure No. 1.1 Tag 20 Field Name Transaction Reference Number Format 16x Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the reference assigned by the Sender to unambiguously identify the message. GUID: For MT798<799> this field should be assigned a value by the corporate, to allow the individual MT798 transaction to be uniquely identified, typically comprising a sequence number that is incremented by 1 for each message generated by the corporate. 1.2 12 Sub-Message Type 3!n M DEFN: This field is used to specify the sub-message type number to allow a specific sub-message to be identified within the MT798, e.g. 770 (LC Application Index), 700 (LC Application Details), 701 (LC Application Extension). RULE: For MT798<799> the sub-message type must have a fixed value of 788.
242
Trade Standards
1.3
77E
Proprietary Message
73x
(Text)
[n*78x] (Text)
Section 2 Field 77E Structure [MT799] No. 2.1 Tag 27A Field Name Message Index/Total Format 1!n/1!n (Message Index)/(Total) Status M Definition / Content / Additional Usage Rules/Guidelines DEFN: This field specifies the sequence number of this message in the series of MT798 messages and the total number of MT798 messages in the series. RULE: For MT798<799> The message index number must have a fixed value of 1, i.e. 1/2. NOTE: This field is not present in the MT799 Message Reference Guide. 2.2 21A Customer Reference Number 16x M DEFN: This field specifies the reference number which has been assigned by the customer or a fixed value of NONREF (e.g. in cases where no reference is available). DEFN: This field specifies the reference number of the bank (i.e. Documentary Credit Number or Guarantee Number) RULE: For MT798<799> The content of this field must be identical to the content of field 21R of MT798<789>. 2.4 21 Related Reference Number 16x O DEFN: This field contains a reference number to the related message. RULE: For MT798<799> This field is not used. 2.5 79 Narrative 35*50x (Narrative) M DEFN: This field contains the free format message.
2.3
20
Transaction Reference Number
16x
7 November 2008
243
Legal Notices
Copyright
SWIFT 2008. All rights reserved. You may copy this publication within your organisation. Any such copy must include these legal notices.
Confidentiality
This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside your organisation without the prior written consent of SWIFT.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest available version on www.swift.com.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the SWIFT logo, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners.
244

MT Forms

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MT Forms

Uploaded by

Copyright:

Available Formats

Solutions

SWIFT for Corporates

Standards MT Message Implementation Guide

SWIFT for Corporates

Legal Notices ............................................................................................................................... 244

Standards MT Messages Implementation Guide

SWIFT for Corporates

General Information on IBANs

Standards MT Messages Implementation Guidelines

Cash Management Standards

Cash Management Standards

SWIFT for Corporates

MT 101 Request for Transfer

between ordering customer accounts in favour of a third party

Standards MT Messages Implementation Guidelines

Cash Management Standards

Customer parties in the MT 101

SWIFT for Corporates

The different scenarios are illustrated in the Business Examples section.

Message usage guidelines

Field 30 Requested Execution Date> Interpretation of date

Standards MT Messages Implementation Guidelines

Cash Management Standards

Additional usage rule

SWIFT for Corporates

Additional usage guideline

Standards MT Messages Implementation Guidelines

Cash Management Standards

SWIFT for Corporates

Remittance Information*** Details of charges Repetitive Sequence B - Transaction Details 2

Standards MT Messages Implementation Guidelines

Cash Management Standards

Transaction Reference Currency/Transaction amount Instructing Party Account With Institution

Remittance Information**** Details of charges

SWIFT for Corporates

Standards MT Messages Implementation Guidelines

Cash Management Standards

Account Servicing Institution Requested Execution Date

:52A: ZZZZUS33 :30:060929

2A. Head office paying from a subsidiary account direct scenario

SWIFT for Corporates

Remittance Information** Details of charges

Standards MT Messages Implementation Guidelines

Cash Management Standards

:21:SPRING-01 :32B:EUR1000, :57A:DDDDDEFF :59:/DE12345678912345678912

SWIFT for Corporates

Standards MT Messages Implementation Guidelines

Cash Management Standards

SWIFT for Corporates

Remittance Information** Details of charges

Standards MT Messages Implementation Guidelines

Cash Management Standards

SWIFT for Corporates

4. Payment made in settlement of a market deal Narrative

Standards MT Messages Implementation Guidelines

Cash Management Standards

:50G:/1234567891 ONECUS44 :30:090123

:21:TR1-ONECAP/4475 :21F:BOTKJT2736ONEC44 :32B:USD927364,00 :59A:BOTKJPJT :71A:SHA

5. Settlement via Intermediary Bank Narrative

SWIFT for Corporates

Standards MT Messages Implementation Guidelines

Cash Management Standards

Remittance Information Details of charges