You are on page 1of 244

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
SWIFT for Corporates

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
2 Cash Management Standards...............................................................................................5
2.1 Payment Initiation....................................................................................................................6
2.2 Exceptions Handling and Investigations ...............................................................................27
2.3 Account Reporting.................................................................................................................30
3 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
4 Securities Standards ...........................................................................................................55
4.1 Settlement, Status and Allegement Messages .....................................................................56
4.2 Reconciliation Messages ......................................................................................................64
4.3 Asset Servicing Messages....................................................................................................73

5 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

2 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 Important information and document names
Courier User input, directory paths, parameter values, place holders, and
system output examples
Underline Added rule/guideline compared to the previous release of the document
Strikethrough Deleted rule/guideline compared to the previous release of the
document

17 December 2008 3
SWIFT for Corporates

1 General Information
1.1 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

4 Standards MT Messages Implementation Guidelines


Cash Management Standards

2 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. General Information: Added general information on the use of IBAN.

2. MT 101 Field 50a (Ordering Customer): Added a usage rule to indicate that a bank
should accept as the ordering customer’s 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.

3. 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.

17 December 2008 5
SWIFT for Corporates

4. MT 101 field 56a (Intermediary): Added a usage guideline with a definition of 'Intermediary
Bank'.

5. MT 101 field 77B (Regulatory Reporting): Added a usage guideline with a list of
recommended codes for use in this field.

6. MT 103, Customer Credit Transfer: Deleted from SCORE.

7. 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.

8. 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.

9. 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.

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


Scope
The MT 101 is sent by the corporate to the financial institution. It is used to move funds from the
ordering customer’s account, serviced at the receiving financial institution or at the account
servicing institution.

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:

6 Standards MT Messages Implementation Guidelines


Cash Management Standards

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 customer’s 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 customer’s 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 7
SWIFT for Corporates

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 For sender/ordering customer:
rules
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 customer’s
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 A bank should accept as the ordering customer’s account number in the
[rule applicable as MT101, field 50F, 50G or 50H depending on bank requirements, the
from 21 November account number that the bank provides themselves in field 25 (Account
2009] Identification) of the MT 940, with the same format, length and
representation.
Field 30 Requested Execution Date> Interpretation of date

8 Standards MT Messages Implementation Guidelines


Cash Management Standards

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 customer’s 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 This field specifies instructions for the account servicing institution of the
ordering customer.
Additional usage rule The usage and interpretation of the codes depends on the agreement
[rule applicable as between the sender and receiver.
from 21 November
A bank must be able to accept the code URGP to indicate a payment with a
2009]
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 Definition: Intermediary Bank means the bank through which the funds will
guideline be transferred to the Beneficiary’s Bank (Account with Institution). In those
[guideline applicable instances where the Beneficiary's Bank (Account with Institution) has a
as from 21 November preferred Intermediary Bank, the Ordering Customer would specify these
2009] 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 customer’s 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 9
SWIFT for Corporates

Additional usage Information that needs to be passed on end-to-end (through to the


guideline 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 To enable consistent handling of regulatory reporting entities in jurisdictions
guideline where this information is relevant in regulatory reporting the following codes
[guideline applicable and structures may be used:
as from 21 November
TAXIDNUM Tax Identification Number
2009]
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 Standards MT Messages Implementation Guidelines


Cash Management Standards

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
PlantOil’s 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 AUG06-
345 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
SWIFT for Corporates

Information flow

SWIFT message
Explanation Format
Header
Sender PLATUS33
Message Type 101
Receiver AAAAUS33
Message text
Sequence A General Information
Sender’s Reference :20:PLANT-12345
Customer Specified Reference* :21R:PLTOL101-56
Message Index/Total :28D:1/1
:50G:/1234567891
Ordering Customer**
PLATUS33
Requested Execution Date :30:060929
Repetitive Sequence B - Transaction Details 1
Transaction Reference :21:TR1-PL
Currency/Transaction amount :32B:USD118982,05
Instructing Party :50L: PLANTOIL AXIM
Account With Institution :57A:BBBBCNBJ
:59:/60648929889
WUNG LU MANUFACTURING
Beneficiary
23 XIAN MEN WAI AVE
BEIJING
:70:/ROC/RA-PL-9876-87
Remittance Information***
/INST/PLANTOIL AXIM
Details of charges :71A:SHA
Repetitive Sequence B - Transaction Details 2

12 Standards MT Messages Implementation Guidelines


Cash Management Standards

Transaction Reference :21:TR2-PL


Currency/Transaction amount :32B:USD50000,
Instructing Party :50L:PLANTOIL PRODUCTIONS
Account With Institution :57A:CCCCGB2L
:59:/0010499
TRISTAN RECORDING STUDIOS
Beneficiary
35 SURREY ROAD
GB-BROMLEY, KENT
:70:/ROC/RA-PL-9876-103
Remittance Information***
/INST/PLANTOIL PRODUCTIONS
Details of charges :71A:SHA
Repetitive Sequence B - Transaction Details 3
Transaction Reference :21:TR3-PL
Currency/Transaction amount :32B:USD377250,
Instructing Party :50L:PLANTOIL COMPANY
Account With Institution :57A:DDDDUS33
:59:/26351-38947
RIVER PAPER COMPANY
Beneficiary
37498 STONE ROAD
US - SAN RAMON, CA
Remittance Information**** :70:/INV/AUG06-345//AUG06-346
Details of charges :71A:SHA

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
SWIFT for Corporates

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 PlantOil’s account (999777) to be debited (=Customer’s 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 Format
Header
Sender PLATUS33
Message Type 101
Receiver AAAAUS33
Message text
Sequence A General Information
Sender’s Reference :20:PLANT-12345
Customer Specified Reference :21R:PLTOL101-56
Message Index/Total :28D:1/1
:50G:/999777
Ordering Customer
PLATUS33

14 Standards MT Messages Implementation Guidelines


Cash Management Standards

Account Servicing Institution :52A: ZZZZUS33


Requested Execution Date :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 subsidiary’s
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 Format
Header
Sender SPRNGB2L
Message Type 101

17 December 2008 15
SWIFT for Corporates

Receiver AAAAGB2L
Message text
Sequence A General Information
Sender’s Reference :20:SPRING-01
Message Index/Total :28D:1/1
Instructing party* :50C:SPRNGB2L
:50H:/9876543
SPRINGS BRANCH
Ordering Customer*
LEICESTER AVENUE
GB-BRIGHTON
Requested Execution Date :30:060929
Repetitive Sequence B - Transaction Details 1
Transaction Reference :21:SPRING-01
Currency/Transaction amount :32B:GBP1000,
Account With Institution :57A:CCCCGB2L
:59:/GB1111111
Beneficiary THOMPSON FACTORY
GB-LIVERPOOL
:70:/INV/TH9876//TH9877
Remittance Information**
/INST/SPRINGS INC
Details of charges :71A:SHA

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 Inc’s 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 Standards MT Messages Implementation Guidelines


Cash Management Standards

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 Format
Header
Sender SPRNGB2L
Message Type 101
Receiver AAAAGB2L
Message text
Sequence A General Information
Sender’s Reference :20:SPRING-01
Message Index/Total :28D:1/1
Instructing party* :50C:SPRNGB2L
:50H:/DE89370400440532013000
SPRINGS BRANCH
Ordering Customer*
ZEIL 5
DE-FRANKFURT
Account Servicing Institution :52A:BBBBDEFF
Requested Execution Date :30:060929
Repetitive Sequence B - Transaction Details 1
Transaction Reference :21:SPRING-01
Currency/Transaction amount :32B:EUR1000,
Account With Institution :57A:DDDDDEFF
Beneficiary :59:/DE12345678912345678912

17 December 2008 17
SWIFT for Corporates

MULLER
DE-FRANKFURT
:70:/INV/MLRAB98
Remittance Information**
/INST/SPRINGS INC
Details of charges :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 office’s 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 Standards MT Messages Implementation Guidelines


Cash Management Standards

BioGen would like to pay transaction 1 from its account 12345, and transaction 2 from its account
67890.

Information flow

SWIFT message
Explanation Format
Header
Sender BIOGNL2A
Message Type 101
Receiver AAAAUS33
Message text
Sequence A General Information
Sender’s Reference :20:BIO-123
Message Index/Total :28D:1/1
Requested Execution Date :30:060929
Repetitive Sequence B - Transaction Details 1
Transaction Reference :21:TR1-BIOG
Currency/Transaction amount :32B:USD30000,
Instructing Party :50L:BIOGEN FRANCE
:50H:/12345
Ordering Customer* BIOGEN US
CA-SAN FRANCISCO
Account With Institution :57A:BBBBMXMM
:59:/11111
EL PUERTO PRODUCTIONS
Beneficiary
AVENIDA CORAL
MEXICO
:70:/ROC/BGF89765
Remittance Information**
/INST/BIOGEN FRANCE

17 December 2008 19
SWIFT for Corporates

Details of charges :71A:SHA


Repetitive Sequence B - Transaction Details 2
Transaction Reference :21:TR2-BIOG
Currency/Transaction amount :32B:USD20000,
Instructing Party :50L: BIOGEN HONG KONG
:50H:/67890
Ordering Customer* BIOGEN US
CA-SAN FRANCISCO
Account With Institution :57A:CCCCUS33
:59:/22222
Beneficiary BIOWORLD
US-NEW JERSEY,NJ
:70: /INV/BW654//BW655//BW656
Remittance Information**
/INST/BIOGEN HONG KONG
Details of charges :71A:SHA

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 Standards MT Messages Implementation Guidelines


Cash Management Standards

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
SWIFT for Corporates

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 OneCapital’s 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 OneCapital’s 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 Format
Header
Sender ONECUS44
Message Type 101
Receiver CHASUS33
Message text
Sequence A General Information
Sender’s Reference :20:AA87999BM
Message Index/Total :28D:1/1

22 Standards MT Messages Implementation Guidelines


Cash Management Standards

:50G:/1234567891
Ordering Customer
ONECUS44
Requested Execution Date :30:090123
Repetitive Sequence B - Transaction Details 1
Transaction Reference :21:TR1-ONECAP/4475
F/X Deal Reference :21F:BOTKJT2736ONEC44
Currency/Transaction amount :32B:USD927364,00
Beneficiary :59A:BOTKJPJT
Details of charges :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 Corp’s account held
with Chase Manhattan Bank and transferred via ICICI Bank serving as an intermediary to
the beneficiary’s bank, ChennaiSun Bank.

17 December 2008 23
SWIFT for Corporates

Information flow

SWIFT message
Explanation Format
Header
Sender FABBUS6S
Message Type 101
Receiver CHASUS33
Message text
Sequence A General Information
Sender’s Reference :20:84549FV
Message Index/Total :28D:1/1
:50G:/654332101
Ordering Customer
FABBUS6S
Requested Execution Date :30:090123
Repetitive Sequence B - Transaction Details 1
Transaction Reference :21:TR1-FABB6755
Currency/Transaction amount :32B:USD23333,00
Intermediary :56A:ICICINBB

Account With Institution :57D:CHENNAISUN BANK


12 SALEM KAMIR ROAD

24 Standards MT Messages Implementation Guidelines


Cash Management Standards

CHENNAI - 6090091

:59:/6069889753
TIGER FASHIONS
Beneficiary
65A RAJAJI SALAI
CHENNAI - 600001
Remittance Information :70:/INV/TGF001935
Details of charges :71A:SHA

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 customer’s
bank of a future credit to the beneficiary customer’s 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
SWIFT for Corporates

The receiving bank would forward the MT 104 cross-border, or start a domestic direct debit
collection.

Message usage guidelines


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 For sender/creditor:
rules
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 This field identifies the type of direct debit instructions contained in the message.
Additional usage rule 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 Customer’s 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 Standards MT Messages Implementation Guidelines


Cash Management Standards

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 Information that needs to be passed on end-to-end (through to the beneficiary
guideline) 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


Scope
This message type is normally used by financial institutions to send information for which another
message type is not applicable.

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
SWIFT for Corporates

Message usage guidelines


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


Scope
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.

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.

Message usage guidelines


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 Standards MT Messages Implementation Guidelines


Cash Management Standards

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


Scope MT 195
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.

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.

Message usage guidelines


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


Scope
This message type is normally used by financial institutions to send information for which another
message type is not applicable.

17 December 2008 29
SWIFT for Corporates

Usage
It must only be used for scenarios pre-agreed between a corporate and its financial institution.

Message usage guidelines


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 owner’s account.

2.3.1 MT 900 Confirmation of Debit


Scope
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.

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.

Message usage guidelines


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 Standards MT Messages Implementation Guidelines


Cash Management Standards

UHB definition This field contains additional information for the Receiver.
Usage Rule: Codes to be used may be agreed to bilaterally.
Additional usage When the clearing system through which the account servicing institution has
guideline sent or received the instruction needs to be reported, the following code may be
[guideline applicable used, placed between slashes ('/') and followed by the clearing system
as from 21 November identification code and/or number.
2009]
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 for Corporates

SWIFT message
Explanation Format
Header
Sender AAAAUS33

Message Type 900

Receiver PLATUS33

Message text
Transaction Reference Number :20:C11126A1378
Related Reference* :21:PLTOL101-56
Account Identification :25:1234567891
Value Date, Currency Code, Amount :32A:060929USD546232,05

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


Scope
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.

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.

Message usage guidelines


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 Standards MT Messages Implementation Guidelines


Cash Management Standards

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 customer’s 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 Format
Header
Sender CCCCGB2L

Message Type 910

Receiver TRSTGB2L

17 December 2008 33
SWIFT for Corporates

Message text
Transaction Reference Number :20:C11126C9224
Related Reference* :21:12345
Account Identification :25:0010499
Value Date, Currency Code, Amount :32A:060929USD50000,
Ordering Customer** :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


Scope
This message is used to transmit detailed information about all entries booked to an account,
serviced by a financial institution.

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 Standards MT Messages Implementation Guidelines


Cash Management Standards

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.

Message usage guidelines


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
SWIFT for Corporates

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 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.
Additional usage rule 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 Debit: USD 546232,05


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 Credit: USD 500000
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 Debit: USD 100000
Transaction type: Settlement of F/X Contract
Reference for the Account Owner: AAAAUS0369PLATUS
Reference of AAAAUS33: 8954321
Value Date: 29 September 2006 Credit: USD 200000
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

Information flow

36 Standards MT Messages Implementation Guidelines


Cash Management Standards

SWIFT message
Explanation Format
Header
Sender AAAAUS33

Message Type 940

Receiver PLATUS33

Message text
Transaction Reference Number :20:123456
Account Identification :25: 1234567891
Statement Number/Sequence Number :28C:123/1
Opening Balance :60F:C060928USD28000,00
1st Transaction* :61:060929D546232,05S101 PLTOL101-
56//C11126A1378
2nd Transaction :61:060929C500000,S103987009//8951234
Info to Acct Owner** :86:/ORDP/COMPUTERSYS INC.
/REMI//INV/78541
3rd Transaction :61:060929D100000,NFEX AAAAUS0369PLATUS
//8954321
4th Transaction :61:060929C200000,NDIVNONREF//8846543
Information to Account Owner :86:DIVIDEND LORAL CORP
PREFERRED STOCK 1ST QUARTER 2006
Closing Book Balance :62F:C060629USD81767,95

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
SWIFT for Corporates

2.3.4 MT 941 Balance Report


Scope
This message is used to transmit balance information, reflecting the situation at the identified
time in field 13D.

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).

Message usage guidelines


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 Standards MT Messages Implementation Guidelines


Cash Management Standards

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


Scope
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).

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.

Message usage guidelines


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
SWIFT for Corporates

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 When the clearing system through which the account servicing institution has
guideline sent or received the instruction needs to be reported, the following code may be
[guideline applicable used, placed between slashes ('/') and followed by the clearing system
as from 21 November identification code and/or number.
2009]
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 Gen’s account
12345:

Value date: 29 September 2006 Debit: USD 30000


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 Expected Credit: USD 3000
Reference for the account owner: DD98765
Reference of AAAAUS33: A8908
Details: Debtor = TELEBOR INC
Value date: 29 September 2006 Credit: USD 100000
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

As per agreement, AAAAUS33 will send an MT 942 message to BIOGNL2A to report these
transactions.

40 Standards MT Messages Implementation Guidelines


Cash Management Standards

Information flow

SWIFT message
Explanation Format
Header
Sender AAAAUS33

Message Type 942

Receiver BIOGNL2A

Message text
Transaction Reference Number :20:8765
Account Identification :25:12345
Statement Number/Sequence Number :28C:218/1
Date/Time Indication :13D:0609290200-0500
1st Transaction* :61:060929D30000,S101TR1-BIOG// A8907
Information to Account Owner** :86:/BENM/EL PUERTO PRODUCTIONS
2nd Transaction :61:060929EC3000,NDDTDD98765//A8908
Info to Account Owner :86:/ORDP/TELEBOR INC
3rd Transaction :61:060929C100000,NTRF NONREF//A8909
Info to Account Owner** :86:/ORDP/BOTTLES AND CO
/REMI//INV/YUI56//YUI57
Number and Sum of Debits :90D:1USD30000,
Number and Sum of Credits :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
SWIFT for Corporates

2.3.6 MT 210 Notice to Receive


Scope
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.

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.

Message usage guidelines


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 This field identifies the account to be credited with the incoming funds
Additional usage rule 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 Standards MT Messages Implementation Guidelines


Cash Management Standards

Information flow

SWIFT message
Explanation Format
Header
Sender BIGCDEFF

Message Type 210

Receiver BNKCGB2L

Message text
Transaction Reference Number :20:4587E254
Account Identification :25: 0010499
Value Date :30:060925
Related Reference* :21: BANA2L6751BIGCFF
Currency Code, Amount :32B: GBP675100,
Ordering Institution :52A:BANAGB2L

Note: *= reference of the underlying EUR/GBP forex deal

17 December 2008 43
SWIFT for Corporates

3 Treasury Markets Standards


3.1 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.

Message usage guidelines


Field UHB definition Additional guideline
82a:Party A This field identifies party A. This field must contain the party
which will receive the amount
bought and which will pay the
amount sold.
87a: Party B This field identifies party B. This field must contain the party
which will pay the amount bought
and which will receive the amount
sold.
77D: Terms and This field specifies the For Non Deliverable Forward
Conditions underlying legal agreement. Opening confirmations, this field
must contain on the first line /VALD/
followed by the valuation date in
format YYYYMMDD and on the

44 Standards MT Messages Implementation Guidelines


Treasury Markets Standards

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 Format
Sender BIGCDEFF
Message Type 300
Receiver BANAGB2L
Message text
General Information :15A:
Sender’s Reference :20:123
Type of Operation :22A:NEWT
Common Reference :22C:BANA2L6751BIGCFF

17 December 2008 45
SWIFT for Corporates

Party A :82A:BIGCDEFF
Party B :87A:BANAGB2L
Transaction Details :15B:
Trade Date :30T:20060921
Value Date :30V:20060925
Exchange Rate :36:0,6751
Currency, Amount Bought :32B:GBP1000000,
Receiving Agent :57A:BANCGB2L
Currency, Amount Sold :33B:EUR675100,
Receiving Agent :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 Format
Sender BIGCDEFF
Message Type 300
Receiver BANAGB2L
Message text
General Information :15A:
Sender’s Reference :20:456
Type of Operation :22A:NEWT
Common Reference :22C:BANA2L7181BIGCFF
Party A :82A:BIGCDEFF
Party B :87A:BANAGB2L
Transaction Details :15B:
Trade Date :30T:20061122
Value Date :30V:20070122
Exchange Rate :36:0,27181
Currency, Amount Bought :32B:USD27181000,
Receiving Agent :57D:NET
Currency, Amount Sold :33B:THB1000000000,
Receiving Agent :57D:NET
Terms and Conditions :77D:/VALD/20070122
/SETC/USD

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 Standards MT Messages Implementation Guidelines


Treasury Markets Standards

Explanation Format
Sender BIGCDEFF
Message Type 300
Receiver BANAGB2L
Message text
General Information :15A:
Sender’s Reference :20:789
Type of Operation :22A:NEWT
Common Reference :22C:BANA2L8235BIGCFF
Party A :82A:BIGCDEFF
Party B :87A:BANAGB2L
Transaction Details :15B:
Trade Date :30T:20070119
Value Date :30V:20070122
Exchange Rate :36:0,28235
Currency, Amount Bought :32B:THB1000000000,
Receiving Agent :57D:NET
Currency, Amount Sold :33B:USD28235000,
Delivery Agent :53A:BANDUS33
Receiving Agent :57A:BANAUS33
Terms and Conditions :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
SWIFT for Corporates

Message usage guidelines


Field UHB definition Additional guideline
82a:Party A This field identifies party A. 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.
87a: Party B This field identifies party B. 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.
77D: Terms and This field specifies the underlying For a floating rate loan/deposit,
Conditions legal agreement. 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).
22A: Type of This field specifies the function of the In case of a new event (trade
Operation message. 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.
32H: Amount to be For a rollover confirmation This field must contain a negative
Settled (22B=ROLL), this field specifies the sign when the amount is received
difference between the previous and from Party A’s point of view.
the new principal amount, with
Normally, the interest is included
interest included when interest is
in this amount when and only
settled through the same cash flow.
when it is netted with the
For a maturity confirmation difference (ROLL) or
(22B=MATU), this field specifies the reimbursement (MATU) of
amount with optional interest to be principal.
paid by the borrower at maturity date.
34x: Currency and This field specifies for For a floating rate loan/deposit,
Interest Amount this field must contain an interest
a new confirmation (22B=CONF), the
amount of zero in the
first interest amount;
confirmation sent at the start of
a rollover confirmation (22B=ROLL), the trade (field 22B contains
the next interest amount; CONF), while it must contain the
actual total interest amount in the
a maturity confirmation (22B=MATU),
confirmation sent at maturity (field
the final interest amount to be settled
22B contains MATU).
at maturity.

48 Standards MT Messages Implementation Guidelines


Treasury Markets Standards

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 Format
Sender BIGCDEFF
Message Type 320
Receiver SAVECHFF
Message text
General Information :15A:
Sender’s Reference :20:ABC
Type of Operation :22A:NEWT
Type of Event :22B:CONF
Common Reference :22C:BIGCFF5495SAVEGG
Party A :82A:SPOCDEF1
Party B :87A:SAVECHGG

17 December 2008 49
SWIFT for Corporates

Transaction Details :15B:


Party A’s Role :17R:L
Trade Date :30T:20060921
Value Date :30V:20060925
Maturity Date :30P:20061025
Currency and Principal Amount :32B:CHF12000000,
Currency and Interest Amount :34E:NCHF15495,
Interest Rate :37G:1,5495
Day Count Fraction :14D:360/360
Settlement Instructions for Amounts :15C:
Payable by Party A.
Intermediary :56A:ANYBCHGG
Receiving Agent :57A:SAVECHGG
Settlement Instructions for Amounts :15D:
Payable by Party B.
Receiving Agent :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 Format
Sender BIGCDEFF
Message Type 320
Receiver SAVECHFF
Message text
General Information :15A:
Sender’s Reference :20:DEF
Type of Operation :22A:NEWT
Type of Event :22B:CONF
Common Reference :22C:BIGCFF0000SAVEGG
Party A :82A:BIGCDEFF

50 Standards MT Messages Implementation Guidelines


Treasury Markets Standards

Party B :87A:SAVECHGG
Terms and Conditions :77D:/FLTR/CHF-ANNUALSR-RFRCBANKS
Transaction Details :15B:
Party A’s Role :17R:L
Trade Date :30T:20061123
Value Date :30V:20061127
Maturity Date :30P:20070227
Currency and Principal Amount :32B:CHF15000000,
Currency and Interest Amount :34E:CHF0,
Interest Rate :37G:0,
Day Count Fraction :14D:360/360
Settlement Instructions for Amounts :15C:
Payable by Party A.
Intermediary :56A:ANYBCHGG
Receiving Agent :57A:SAVECHGG
Settlement Instructions for Amounts :15D:
Payable by Party B.
Receiving Agent :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 Format
Sender BIGCDEFF
Message Type 320
Receiver SAVECHFF
Message text
General Information :15A:
Sender’s Reference :20GHI
Related Reference :21:DEF
Type of Operation :22A:NEWT
Type of Event :22B:MATU
Common Reference :22C:BIGCFF0275SAVEGG
Party A :82A:BIGCDEFF
Party B :87A:SAVECHGG
Terms and Conditions :77D:/FLTR/CHF-ANNUALSR-RFRCBANKS
Transaction Details :15B:
Party A’s Role :17R:L
Trade Date :30T:20061123
Value Date :30V:20061127
Maturity Date :30P:20070227
Currency and Principal Amount :32B:CHF15000000,

17 December 2008 51
SWIFT for Corporates

Currency and Amount to be Settled :32H:NCHF15103125,


Currency and Interest Amount :34E:NCHF103125,
Interest Rate :37G:2,75
Day Count Fraction :14D:360/360
Settlement Instructions for Amounts :15C:
Payable by Party A.
Intermediary :56A:ANYBCHGG
Receiving Agent :57A:SAVECHGG
Settlement Instructions for Amounts :15D:
Payable by Party B.
Receiving Agent :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 Option Buyer Currency Buyer


Code1 Code 2 Code 3 Currency =
Field 32B
Buy Call A or E Ccy Sender Sender
Buy Put A or E Ccy Sender Receiver
Sell Call A or E Ccy Receiver Receiver
Sell Put A or E Ccy Receiver Sender

52 Standards MT Messages Implementation Guidelines


Treasury Markets Standards

Message usage guidelines


Field UHB definition Additional guideline
23:Further Identification This field specifies whether, This field is composed of 3 codes
from the sender's point of and a currency. The currency
view, the option is sold or code must be the same as the
bought, is a put or call, and currency indicated in field 32B.
indicates the style and the
The first code specifies whether
underlying currency.
the option is bought or sold, the
second code specifies whether
the option is a Put or a Call.
31G:Expiry Details This field specifies the date, For matching reasons, it is
time and location at which the recommended to use for the
option expires. 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.
33B:Counter Currency and This field specifies the counter This field contains the currency
Amount currency and amount. The exchanged against the underlying
counter currency is the currency of the option (as
currency which is to be indicated in field 32B).
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 Format
Sender BIGCDEFF
Message Type 300
Receiver BANAGB2L
Message text
Transaction Reference Number :20:00A
Related Reference :21:00A
Common Reference :22:NEW/BANA2L5432BIGCFF
Further Identification :23:BUY/CALL/EUR/A
Date Contract Agreed :30:20061123
Earliest Exercise Date :31C:20061124
Expiry Details :31G:20070227/1000/DEFR
Settlement Type :26F:PRINCIPAL

17 December 2008 53
SWIFT for Corporates

Underlying Currency and Amount :32B:EUR10000000,


Strike Price :36:1,5432
Counter Currency and Amount :33B:USD15432000,
Premium Price :37K:PCT5,
Premium Amount :34P:EUR500000,
Account With Institution :57A:BANADEFF
Terms and Conditions :77D:/ISDA/20030712

54 Standards MT Messages Implementation Guidelines


Securities Standards

4 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
SWIFT for Corporates

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.

Message usage guidelines


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 Standards MT Messages Implementation Guidelines


Securities Standards

• 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 Format
Header
Sender ABCDUS33
Message Type 541
Receiver CUSTUS33

Message text

17 December 2008 57
SWIFT for Corporates

Sequence A General Information


Start of Block :16R:GENL
Sender’s Reference :20C::SEME//TRADECP001
Function of the Message :23G:NEWM
End of Block :16S:GENL
Sequence B – Trade Details
Start of Block :16R:TRADDET
Trade Date :98A::TRAD//20061215
Settlement Date :98A::SETT//20061218
Deal Price :90B::DEAL//PRCT/103,867
Identification of the securities :35B:ISIN US345397TT06
End of Block :16S:TRADDET
Sequence C – Financial Instrument Account
Start of Block :16R:FIAC
Quantity to be received :36B::SETT//FAMT/100000,
Safekeeping account :97A::SAFE//1234567891
End of Block :16S:FIAC
Sequence E – Settlement Details
Start of Block :16R:SETDET
Type of settlement transaction: regular trade :22F::SETR//TRAD
Repetitive Sequence E1 – Settlement Parties*
Start of Block :16R:SETPRTY
Seller :95P::SELL//BROKUS33
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Delivering Agent** :95R::DEAG/DTCYID/03124569
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Place of settlement :95P::PSET///DTCYUS33
End of Block :16S:SETPRTY
Repetitive Sequence E3 – Amounts
Start of Block :16R:AMT
Settlement Amount :19A::SETT//USD103867,
End of Block :16S:AMT
Start of Block :16R:AMT
Deal Amount :19A::DEAL//USD103867,
End of Block :16S:AMT

58 Standards MT Messages Implementation Guidelines


Securities Standards

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

Message usage guidelines


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)

New or updated market practices are published on regular basis on www.smpg.info.

17 December 2008 59
SWIFT for Corporates

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 Format
Header
Sender CUSTUS33
Message Type 548
Receiver ABCDUS33

Message text
Sequence A General Information
Start of Block :16R:GENL
Sender’s Reference :20C::SEME//STATUS123456
Function of the Message :23G:INST
Sequence A1 Linkages
Start of Block :16R:LINK
Link to the instruction the MT 548 is about :20C::RELA//TRADECP001
End of Block :16S:LINK
End of Block :16S:GENL
Sequence A2 – Status
Start of Block :16R:STAT
Settlement Status :25D::SETT//PEND
Sequence A2a – Reason
Start of Block :16R:REAS
Reason (Transaction is pending settlement) :24B::PEND//FUTU
End of Block :16S:REAS
End of Block :16S:STAT
Sequence B – Settlement Transaction Details
Start of Block :16R:SETTRAN
Identification of the securities :35B:ISIN US345397TT06
Quantity to be received :36B::SETT//FAMT/100000,
Settlement Amount :19A::SETT//USD103867,
Safekeeping account :97A::SAFE//1234567891
Type of settlement transaction: regular trade :22F::SETR//TRAD

60 Standards MT Messages Implementation Guidelines


Securities Standards

Receive/Deliver Indicator :22F::REDE//RECE


Payment Indicator :22F::PAYM//APMT
Trade Date :98A::TRAD//20061215
Settlement Date :98A::SETT//20061218
Repetitive Sequence B1 – Settlement Parties
Start of Block :16R:SETPRTY
Seller :95P::SELL//BROKUS33
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Delivering Agent* :95R::DEAG/DTCYID/03124569
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Place of settlement :95P::PSET///DTCYUS33
End of Block :16S:SETPRTY
End of Block :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
SWIFT for Corporates

The MT 547 is used to confirm a Deliver Against Payment Instruction

Message usage guidelines


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 Format
Header
Sender CUSTUS33
Message Type 545
Receiver ABCDUS33

Message text
Sequence A General Information
Start of Block :16R:GENL
Sender’s Reference :20C::SEME//CONF1234
Function of the Message :23G:NEWM
Sequence A1 Linkages
Start of Block :16R:LINK
Link to the instruction the MT 548 is about :20C::PREV//TRADECP001
End of Block :16S:LINK
End of Block :16S:GENL
Sequence B - Trade Details
Start of Block :16R:TRADDET
Trade Date :98A::TRAD//20061215
Settlement Date :98A::ESET//20061218

62 Standards MT Messages Implementation Guidelines


Securities Standards

Deal Price :90B::DEAL//PRCT/103,867


Identification of the securities :35B:ISIN US345397TT06
End of Block :16S:TRADDET
Sequence C – Financial Instrument Account
Start of Block :16R:FIAC
Quantity to be received :36B::ESTT//FAMT/100000,
Safekeeping account :97A::SAFE//1234567891
End of Block :16S:FIAC
Sequence E – Settlement Details
Start of Block :16R:SETDET
Type of settlement transaction: regular trade :22F::SETR//TRAD
Repetitive Sequence E1 – Settlement Parties
Start of Block :16R:SETPRTY
Seller :95P::SELL//BROKUS33
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Delivering Agent :95R::DEAG/DTCYID/03124569
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Place of settlement :95P::PSET///DTCYUS33
End of Block :16S:SETPRTY
Repetitive Sequence E3 – Amounts
Start of Block :16R:AMT
Settlement Amount :19A::ESTT//USD103867,
End of Block :16S:AMT
Start of Block :16R:AMT
Deal Amount :19A::DEAL//USD103867,
End of Block :16S:AMT
End of Block :16S:SETDET

17 December 2008 63
SWIFT for Corporates

4.1.4 MT 578 Settlement Allegement

Scope
The MT 578 is sent by the custodian bank to the corporate.
This message is used to:

• 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)

Message usage guidelines


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)

New or updated market practices are published on regular basis on www.smpg.info.

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 Standards MT Messages Implementation Guidelines


Securities Standards

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
The MT 537 is sent by the custodian bank to the corporate. This message is used to:

• 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)

Message usage guidelines


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
SWIFT for Corporates

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)

New or updated market practices are published on regular basis on www.smpg.info.

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 Format
Header
Sender CUSTUS33
Message Type 537
Receiver ABCDUS33

Message text
Sequence A General Information
Start of Block :16R:GENL
Page Number/ Continuation Indicator :28E::00001/ONLY
Statement Number :13A::STAT//001
Sender’s Reference :20C::SEME//REPORT1
Function of the Message :23G:NEWM
Statement Date :98A::STAT//20061216
Statement Frequency Indicator (Daily) :22F::SFRE//DAIL
Complete/Update Indicator (Complete) :22F::CODE//COMP
Statement Structure Type Indicator :22F::STST//STAT
Safekeeping Account :97A::SAFE//1234567891
Activity Flag :17B::ACTI//Y
End of Block :16S:GENL
Sequence B – Status
Start of Block :16R:STAT

66 Standards MT Messages Implementation Guidelines


Securities Standards

Settlement Status :25D::SETT//PEND


Sequence B1- Reason
Start of Block :16R:REAS
Reason (Transaction is pending settlement) :24B::PEND//FUTU
End of Block :16S:REAS
Sequence B2 –Transaction
Start of Block :16R:TRAN
Sequence B2a Linkages
Start of Block :16R:LINK
Link to the instruction the MT 548 is about :20C::RELA//TRADECP001
End of Block :16S:LINK
Sequence B2b Transaction Details
Start of Block :16R:TRANSDET
Identification of the securities :35B:ISIN US345397TT06
Quantity to be received :36B::PSTA//FAMT/100000,
Settlement Amount :19A::PSTA//USD103867,
Transaction Indicator: Settlement and Clearing :22F::TRAN//SETT
Activity
Type of settlement transaction: regular trade :22F::SETR//TRAD
Receive/Deliver Indicator :22F::REDE//RECE
Payment Indicator :22F::PAYM//APMT
Trade Date :98A::TRAD//20061215
Settlement Date :98A::SETT//20061218
Repetitive Sequence B2b1 – Settlement Parties
Start of Block :16R:SETPRTY
Seller :95P::SELL//BROKUS33
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Delivering Agent* :95R::DEAG/DTCYID/03124569
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Place of settlement :95P::PSET///DTCYUS33
End of Block :16S:SETPRTY
End of Block :16S:TRANSDET
End of Block :16S:TRAN
End of Block :16S:STAT
**

17 December 2008 67
SWIFT for Corporates

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
The MT 536 is sent by the custodian bank to the corporate.
This message is used to:

• 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)

Message usage guidelines


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)

New or updated market practices are published on regular basis on www.smpg.info.

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 Standards MT Messages Implementation Guidelines


Securities Standards

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 Format
Header
Sender CUSTUS33
Message Type 536
Receiver ABCDUS33

Message text
Sequence A General Information
Start of Block :16R:GENL
Page Number/ Continuation Indicator :28E::00001/ONLY
Statement Number :13A::STAT//001
Sender’s Reference :20C::SEME//REPORT1
Function of the Message :23G:NEWM
Statement Period :69A::STAT//20061217/20061218
Statement Frequency Indicator (Daily) :22F::SFRE//DAIL
Complete/Update Indicator (Complete) :22F::CODE//COMP
Safekeeping Account :97A::SAFE//1234567891
Activity Flag :17B::ACTI//Y
Sub-safekeeping Statement :17B::CONS//N
End of Block :16S:GENL
Sequence B – Subsafekeeping Account
Start of Block :16R:SUBSAFE
Sequence B1- Financial Instrument
Start of Block :16R:FIN
Identification of the securities :35B:ISIN US345397TT06
Sequence B1a Transaction
Start of Block :16R:TRAN
Sequence B1a1 Linkages
Start of Block :16R:LINK
Link to the instruction the MT 548 is about :20C::RELA//TRADECP001
End of Block :16S:LINK
Sequence B1a2 Transaction Details
Start of Block :16R:TRANSDET

17 December 2008 69
SWIFT for Corporates

Quantity to be received :36B::PSTA//FAMT/100000,


Settlement Amount :19A::PSTA//USD103867,
Transaction Indicator: Settlement and Clearing :22F::TRAN//SETT
Activity
Type of settlement transaction: regular trade :22F::SETR//TRAD
Receive/Deliver Indicator :22F::REDE//RECE
Payment Indicator :22F::PAYM//APMT
Trade Date :98A::TRAD//20061215
Settlement Date :98A::ESET//20061218
Repetitive Sequence B2b1 – Settlement Parties
Start of Block :16R:SETPRTY
Seller :95P::SELL//BROKUS33
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Delivering Agent* :95R::DEAG/DTCYID/03124569
End of Block :16S:SETPRTY
Start of Block :16R:SETPRTY
Place of settlement :95P::PSET///DTCYUS33
End of Block :16S:SETPRTY
End of Block :16S:TRANSDET
End of Block :16S:TRAN
*
End of Block :16S:FIN
**
End of Block :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 Standards MT Messages Implementation Guidelines


Securities Standards

Scope
The MT 535 is sent by the custodian bank to the corporate.
This message is used to:

• 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)

Message usage guidelines


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)

New or updated market practices are published on regular basis on www.smpg.info.

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 Format
Header
Sender CUSTUS33

17 December 2008 71
SWIFT for Corporates

Message Type 535


Receiver ABCDUS33

Message text
Sequence A General Information
Start of Block :16R:GENL
Page Number/ Continuation Indicator :28E::00001/ONLY
Statement Number :13A::STAT//001
Sender’s Reference :20C::SEME//REPORT1
Function of the Message :23G:NEWM
Statement Date :98A::STAT//20061218
Statement Frequency Indicator (Daily) :22F::SFRE//DAIL
Complete/Update Indicator (Complete) :22F::CODE//COMP
Statement Type (Custody) :22F::STTY//CUST
Statement Basis (Settled positions) :22F::STBA//SETT
Safekeeping Account :97A::SAFE//1234567891
Activity Flag :17B::ACTI//Y
Sub-safekeeping Statement :17B::CONS//N
End of Block :16S:GENL
Sequence B – Subsafekeeping Account
Start of Block :16R:SUBSAFE
Sequence B1- Financial Instrument
Start of Block :16R:FIN
Identification of the securities :35B:ISIN US345397TT06
Balance :93B::AGGR//FAMT/100000,
Balance available :93B::AVAI//FAMT/100000,
Balance not available :93B::NAVL//FAMT/0,
End of Block :16R:FIN
*
End of Block :16S:SUBSAFE

Note:
* Other holdings will follow here.

72 Standards MT Messages Implementation Guidelines


Securities Standards

4.2.4 MT 586 Statement of Settlement Allegements

Scope
The MT 586 is sent by the custodian bank to the corporate.
This message is used to:

• 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)

Message usage guidelines


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)

New or updated market practices are published on regular basis on www.smpg.info.

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
SWIFT for Corporates

4.3.1 Asset Servicing Messages Scope


MT 564
The MT 564 is sent by the custodian bank to the corporate.
This message is used to:

• 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)
• 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)

MT 565
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 Standards MT Messages Implementation Guidelines


Securities Standards

MT 566
The MT 566 is sent by the custodian bank to the corporate.
This message is used to:

• 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)

MT 567
The MT 567 is sent by the custodian bank to the corporate.
This message is used to:

• 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


Message usage guidelines
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

New or updated market practices are published on regular basis on www.smpg.info.

17 December 2008 75
SWIFT for Corporates

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 Format
Header
Sender CUSTUS33
Message Type 564
Receiver ABCDUS33

Message text
Sequence A General Information
Start of block :16R:GENL
Corporate action reference :20C::CORP//RDM3437592
Senders reference :20C::SEME//1997189-012
Function of the message :23G:NEWM
Final maturity :22F::CAEV//REDM
Mandatory indicator :22F::CAMV//MAND
Details are complete :25D::PROC//COMP
End of block :16S:GENL
Sequence B Underlying Securities
Start of block :16R:USECU
Underlying securities :35B:ISIN US345397TT06
Description of the instrument
Sequence B2 Account Information
Start of block :16R:ACCTINFO
Safekeeping account :97A::SAFE//1234567891
Eligible face amount balance :93B::ELIG//FAMT/100000,
End of block :16S:ACCTINFO

76 Standards MT Messages Implementation Guidelines


Securities Standards

End of block :16S:USECU


Sequence D Corporate Action Details
Start of block :16R:CADETL
Redemption date :98A::REDM//20070315
End of block :16S:CADETL
Sequence E Corporate Action Options
Start of block :16R:CAOPTN
CA option number :13A::CAON//001
Cash option :22F::CAOP//CASH
Currency offered :11A::OPTN//USD
Default option :17B::DFLT//Y
Payment date :98A::PAYD//20070315
Redemption price (100% par) :90A::OFFR//PRCT/100,
End of block :16S:CAOPTN

When the details of the entitlement are known, Custodian Bank CUSTUS33 sends an entitlement
notification.

MT 564 Corporate Action Notification


Explanation Format
Header
Sender CUSTUS33
Message Type 564
Receiver ABCDUS33

Message text
Sequence A General Information
Start of block :16R:GENL
Corporate action reference :20C::CORP//RDM3437592
Senders reference :20C::SEME//1997189-013
Function of the message :23G:REPE
Final maturity :22F::CAEV//REDM
Mandatory indicator :22F::CAMV//MAND
Details are complete :25D::PROC//COMP
End of block :16S:GENL
Sequence B Underlying Securities
Start of block :16R:USECU
Underlying securities :35B:ISIN US345397TT06
Description of the instrument
Sequence B2 Account Information

17 December 2008 77
SWIFT for Corporates

Start of block :16R:ACCTINFO


Safekeeping account :97A::SAFE//1234567891
Eligible face amount balance :93B::ELIG//FAMT/100000,
End of block :16S:ACCTINFO
End of block :16S:USECU
Sequence D Corporate Action Details
Start of block :16R:CADETL
Redemption date :98A::REDM//20070315
End of block :16S:CADETL
Sequence E Corporate Action Options
Start of block :16R:CAOPTN
CA option number :13A::CAON//001
Cash option :22F::CAOP//CASH
Currency offered :11A::OPTN//USD
Default option :17B::DFLT//Y
Redemption price (100% par) :90A::OFFR//PRCT/100,
Sequence E1 Securities Movement
Start of block :16R:SECMOVE
Debit indicator :22H::CRDB//DEBT
Underlying securities to be debited :35B:ISIN US345397TT06
Quantity to be debited :36B::ENTL//FAMT/100000,
Date securities will be debited :98A::PAYD//20070315
End of block :16S:SECMOVE
Sequence E2 Cash Movement
Start of block :16R:CASHMOVE
Credit indicator :22H::CRDB//CRED
Gross amount :19B::GRSS//EUR105900,
Entitled amount :19B::ENTL//EUR105900,
Payment date :98A::PAYD//20070315
End of block :16S:CASHMOVE
End of block :16S:CAOPTN

When the payment is done, Custodian Bank CUSTUS33 sends a confirmation message.

MT 566 Corporate Action Confirmation


Explanation Format
Header
Sender CUSTUS33

78 Standards MT Messages Implementation Guidelines


Securities Standards

Message Type 566


Receiver ABCDUS33

Message text
Sequence A General Information
Start of block :16R:GENL
Corporate action reference :20C::CORP//RDM3437592
Senders reference :20C::SEME//1997189-014
Function of the message :23G:NEWM
Final maturity :22F::CAEV//REDM
End of block :16S:GENL
Sequence B Underlying Securities
Start of block :16R:USECU
Safekeeping account :97A::SAFE//1234567891
Underlying securities :35B:ISIN US345397TT06
Description of the instrument
Eligible face amount balance :93B::ELIG//FAMT/100000,
Confirmed balance :93B::CONB//FAMT/100000,
End of block :16S:USECU
Sequence C Corporate Action Details
Start of block :16R:CADETL
Redemption date :98A::REDM//20070315
Date securities will be debited :98A::PAYD//20070315
End of block :16S:CADETL
Sequence D Corporate Action Confirmation
Start of block :16R:CACONF
CA option number :13A::CAON//001
Cash option :22F::CAOP//CASH
Redemption price (100% par) :90A::OFFR//PRCT/100,
Sequence D1 Securities Movement
Start of block :16R:SECMOVE
Debit indicator :22H::CRDB//DEBT
Underlying securities to be debited :35B:ISIN US345397TT06
Quantity to be debited :36B::PSTA//FAMT/100000,
Posting date :98A::POST//20070315
End of block :16S:SECMOVE
Sequence D2 Cash Movement
Start of block :16R:CASHMOVE

17 December 2008 79
SWIFT for Corporates

Credit indicator :22H::CRDB//CRED


Gross amount :19B::GRSS//EUR105900,
Entitled amount :19B::PSTA//EUR105900,
Posting date :98A::POST//20070315
Value date :98A::VALU//20070315
End of block :16S:CASHMOVE
End of block :16S:CACONF

80 Standards MT Messages Implementation Guidelines


Trade Standards

5 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-to-
bank 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
SWIFT for Corporates

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 sub-
types 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-to-
corporate 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 Standards MT Messages Implementation Guidelines


Trade Standards

Credit, etc. The Index message contains additional fields specific to corporate-to-bank and bank-
to-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
SWIFT for Corporates

84 Standards MT Messages Implementation Guidelines


Trade Standards

17 December 2008 85
SWIFT for Corporates

Message Tables
Import Documentary Credit
MT Sub- Status Max. Name Base
Message Messag Occur Message
Type e Type Type
Application for issuance of Documentary Credit - C2B
MT798 770 M 1 LC Application Index
MT798 700 M 1 LC Application Details MT700
MT798 701 O 3 LC Application Extension MT701
Notification of issuance of Documentary Credit - B2C
MT798 771 M 1 LC Notification of Issuance Index
MT798 700 M 1 LC Notification of Issuance Details MT700
MT798 701 O 3 LC Notification of Issuance Extension MT701
Request for amendment of Documentary Credit - C2B
MT798 772 M 1 LC Amendment Request Index
MT798 707 M 1 LC Amendment Request Details MT707
Notification of amendment of Documentary Credit - B2C
MT798 773 M 1 LC Notification of Amendment Index
MT798 707 M 1 LC Notification of Amendment Details MT707

86 Standards MT Messages Implementation Guidelines


Trade Standards

Export Documentary Credit


MT Sub- Status Max. Name Base
Message Messag Occur Message
Type e Type Type
Advice of Documentary Credit – B2C
MT798 774 M 1 LC Advice Index
MT798 700 M 1 LC Advice Details MT700
MT798 701 O 3 LC Advice Extension MT701
Advice of amendment of Documentary Credit – B2C
MT798 776 M 1 LC Amendment Index
MT798 707 M 1 LC Amendment Details MT707
Advice of Third Bank Documentary Credit – B2C
MT798 780 M 1 LC Third Bank Advice Index
MT798 710 M 1 LC Third Bank Advice Details MT710
MT798 711 0 3 LC Third Bank Advice Extension MT711
Advice of Transfer Documentary Credit – B2C
MT798 782 M 1 LC Transfer Advice Index
MT798 720 M 1 LC Transfer Advice Details MT720
MT798 721 O 3 LC Transfer Advice Extension MT721

Guarantee / Standby Letter of Credit


MT Sub- Status Max. Name Base
Message Message Occur Message
Type Type Type
Application for issuance of Guarantee / Standby Letter of Credit – C2B
MT798 761 or M 1 Guarantee Application Index
784 M 1 Standby LC Application Index
MT798 760 M 1 Guarantee Request Details MT760
Notification of Guarantee / Standby Letter of Credit – B2C
MT798 762 or M 1 Guarantee Notification Index
785 M 1 Standby LC Notification Index
MT798 760 M 1 Guarantee Amendment Request Details MT767
Notification of amendment of Guarantee / Standby Letter of Credit – B2C
MT798 764 or M 1 Guarantee Amendment Notification Index
787 M 1 Standby LC Amendment Notification Index
MT798 767 M 1 Guarantee Amendment Notification Details MT767
Advice of Reduction or Release – B2C
MT798 766 M 1 Advice of Release / Reduction Index
MT798 769 M 1 Advice of Release / Reduction Details MT769

17 December 2008 87
SWIFT for Corporates

MT Sub- Status Max. Name Base


Message Message Occur Message
Type Type Type
Free Format Message – C2B
MT798 788 M 1 Free Format Message Index
MT798 799 M 1 Free Format Message Details MT799
Notification of Guarantee / Standby Letter of Credit – B2C
MT798 789 M 1 Free Format Message Index
MT798 799 M 1 Free Format Message Details MT799

88 Standards MT Messages Implementation Guidelines


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
SWIFT for Corporates

Import Documentary Credit


MT Sub- Status Max. Name Base
Message Message Occur Message
Type Type Type
Application for issuance of Documentary Credit - C2B
MT798 770 M 1 LC Application Index
MT798 700 M 1 LC Application Details MT700
MT798 701 O 3 LC Application Extension MT701
Notification of issuance of Documentary Credit - B2C
MT798 771 M 1 LC Notification of Issuance Index
MT798 700 M 1 LC Notification of Issuance Details MT700
MT798 701 O 3 LC Notification of Issuance Extension MT701
Request for amendment of Documentary Credit - C2B
MT798 772 M 1 LC Amendment Request Index
MT798 707 M 1 LC Amendment Request Details MT707
Notification of amendment of Documentary Credit - B2C
MT798 773 M 1 LC Notification of Amendment Index
MT798 707 M 1 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 Mandatory
O Optional
Usage Details DEFN Definition
RULE Usage Rule. Must be adhered to
GUID Usage Guidance. Recommended practice
CODE Applicable Code Values
NOTE Remark
Format a alphabetic, capital letters (A through Z), upper case
only
c alpha-numeric capital letters (upper case), and
digits only
n numeric, digits (0 through 9) only
x SWIFT X set:
• A to Z
• a to z
• 0 to 9
• / - ? : ( ) . , ’ + SPACE CrLf
! fixed length

90 Standards MT Messages Implementation Guidelines


Trade Standards

d decimals, including decimal comma ',' preceding


the fractional part. The fractional part may be
missing, but the decimal comma must always be
present
Codes l or

5.1.1 Application for Documentary Credit


Scope
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 applicant’s bank according to the
terms, and conditions under which the requested credit is to be opened.

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
SWIFT for Corporates

MT 798<770> - LC Application Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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
[n*78x] (Text)
Receiver.
RULE: For MT798<770> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the total
(Message Index)/(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 Standards MT Messages Implementation Guidelines


Trade Standards

2.2 21A Customer Reference 16x M DEFN: This field specifies the Application number which
Number has been assigned by the Applicant.
2.3 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was created.
Time Date format YYYYMMDD. Time format: HHMM.
(Date)(Time)
2.4 24D Method of Issue 4!c[/35x] M DEFN: This field specifies the method by which a
documentary credit is to be issued.
(Method)(Additional Information)
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.5 53C Debit Account Number /34x O DEFN: This field specifies the number of the account of
the Applicant to be used for settlement.
(Account)
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 3!a M DEFN: This field specifies the party(s) responsible for the
By documentary credit charges.
(Code)
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
SWIFT for Corporates

2.7 73 Charges Information 6*35x O DEFN: This field specifies additional information for the
documentary credit charges.
(Narrative)
RULE: For MT798<770>, must only be used if field 71A
'Bank Charges Payable By' is = OTH.
2.8 25A Charges Debit Account /34x O DEFN: This field specifies the number of account of the
Number Applicant to be used for settlement of charges.
(Account)
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 3!a O DEFN: This field specifies the party(s) responsible for the
Payable By documentary credit confirmation charges.
(Code)
CODES:
BEN = Beneficiary pays confirmation charges
OUR = Applicant pays confirmation charges
2.10 58a Advising Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the bank through which the
documentary credit is to be advised/confirmed to the
4!a2!a2!c[3!c] (Identifier Code)
beneficiary.
D [/1!a][/34x] (Party Identifier)
RULE: When specified in option A, the identifier code
4*35x (Name & Address) must be the SWIFT BIC8 or BIC11 for the advising bank.

94 Standards MT Messages Implementation Guidelines


Trade Standards

2.11 29T Transport Mode 4!c[/35x] O DEFN: This field specifies the mode of transport for the
shipment(s) covered by the documentary credit.
(Code)(Narrative)
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 35x O DEFN: This field specifies a reference number of a
Reference Number forward contract used to hedge currency risk.
(Text)
2.13 45C Applicant Undertaking 100*65x O DEFN: This field specifies the undertaking clause of the
applicant.
(Narrative)
2.14 29A Customer Contact 4*35x O DEFN: This field specifies the contact details of the
corporate.
(Narrative)

2.15 72C Corporate to Bank 6*35x O DEFN: This field specifies additional information for the
Information issuing bank.
(Narrative)

17 December 2008 95
SWIFT for Corporates

MT 798<700> - LC Application Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<700> 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<700> the sub-message type must
have a fixed value of 700.
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
[n*78x] (Text)
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. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 Standards MT Messages Implementation Guidelines


Trade Standards

2.2 21A Customer Reference 16x M DEFN: This field specifies the Application number
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 M DEFN: This field specifies the number of this message
in the series of messages sent for a documentary
(Number)(Total)
credit, and the total number of messages in the series.
2.4 40A Form of Documentary 24x M DEFN: This field specifies the type of credit.
Credit
(Type) CODES: IRREVOCABLE | REVOCABLE
|IRREVOCABLE TRANSFERABLE | REVOCABLE
TRANSFERABLE | IRREVOCABLE STANDBY |
REVOCABLE STANDBY | IRREVOC TRANS
STANDBY
2.5 20 Documentary Credit 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the Sender.
RULE: For MT798<700> this field must specify a
documentary credit number, pre-assigned by the
applicant’s bank, or a fixed value of NONREF.
2.6 23 Reference to Pre-Advice 16x O 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 O DEFN: This field specifies the date on which the
issuing bank (Sender) considers the documentary
(Date)
credit as being issued.
RULE: For MT798<700> this field is not used.
2.8 40E Applicable Rules 30x[/35x] M DEFN: This field specifies the rules the credit is
subject to.
(Applicable Rules)(Narrative)
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
SWIFT for Corporates

2.9 31D Date and Place of Expiry 6!n29x M DEFN: This field specifies the latest date for
presentation under the documentary credit and the
(Date)(Place)
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] (Party Identifier) O DEFN: This field specifies the bank of the applicant
customer, if different from the issuing bank.
4!a2!a2!c[3!c] (Identifier Code)
GUID: For MT798<700> this field is not required.
D [/1!a][/34x] (Party Identifier)
4*35x (Name & Address)
2.11 50 Applicant 4*35x M DEFN: This field specifies the party on behalf of which
the documentary credit is being issued.
(Name & Address)
2.12 59 Beneficiary [/34x] (Account M DEFN: This field specifies the party in favour of which
the documentary credit is being issued.
4*35x) (Name & Address)
GUID: For MT798<700>, if the Beneficiary account
number is specified, Field: 58a (Advising Bank) should
also be specified in the MT798<770>.
2.13 32B Currency Code, Amount 3!a15d M DEFN: This field contains the currency code and
amount of the documentary credit.
(Currency)(Amount)
2.14 39A Percentage Credit 2n/2n O DEFN: This field specifies the tolerance relative to the
Amount Tolerance documentary credit amount as a percentage plus
(Tolerance 1)(Tolerance 2)
and/or minus that amount.
RULE: MT798<700>, if field 39A is used, field 39B
must not be used.
2.15 39B Maximum Credit Amount 13x O 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 Standards MT Messages Implementation Guidelines


Trade Standards

2.16 39C Additional Amounts 4*35x O DEFN: This field specifies any additional amounts
Covered available to the beneficiary under the terms of the
(Narrative)
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) M DEFN: This field identifies the bank with which the
credit is available (the place for presentation) and an
14x (Code)
indication of how the credit is available.
D 4*35x (Name & Address)
CODES: BY ACCEPTANCE | BY DEF PAYMENT | BY
14x (Code) 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 O DEFN: This field specifies the tenor of drafts to be
drawn under the documentary credit.
(Narrative)
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] (Party Identifier) O DEFN: This field identifies the drawee of the drafts to
be drawn under the documentary credit.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<700> only used if field 41a
D [/1!a][/34x] (Party Identifier)
'Available By' is not = BY DEF PAYMENT or not = BY
4*35x (Name & Address) 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
SWIFT for Corporates

2.20 42M Mixed Payment Details 4*35x O DEFN: This field specifies the payment dates, amounts
and/or method for their determination in a
(Narrative)
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 O DEFN: This field specifies the payment date or method
for its determination in a documentary credit which is
(Narrative)
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 O DEFN: This field specifies whether or not partial
shipments are allowed under the documentary credit.
(Narrative)
GUID: May be a specified using one of the following
recommended code words ALLOWED | NOT
ALLOWED.
2.23 43T Transhipment 1*35x O DEFN: This field specifies whether or not transhipment
is allowed under the documentary credit.
(Narrative)
GUID: May be a specified using one of the following
recommended code words ALLOWED | NOT
ALLOWED.
2.24 44A Place of Taking in 1*65x O DEFN: This field specifies the place of taking in charge
Charge/Dispatch from (in case of a multimodal transport document), the
(Narrative)
.../Place of Receipt 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.
2.25 44E Port of Loading/Airport of 1*65x O DEFN: This field specifies the port of loading or airport
Departure of departure to be indicated on the transport
(Narrative)
document.
2.26 44F Port of Discharge/Airport 1*65x O DEFN: This field specifies the port of discharge or
of Destination airport of destination to be indicated on the transport
(Narrative)
document.

100 Standards MT Messages Implementation Guidelines


Trade Standards

2.27 44B Place of Final 1*65x O DEFN: This field specifies the final destination or place
Destination/For of delivery to be indicated on the transport document.
(Narrative)
Transportation to .../Place
of Delivery
2.28 44C Latest Date of Shipment 6!n O DEFN: This field specifies the latest date for loading on
board/dispatch/taking in charge.
(Date)
2.29 44D Shipment Period 6*65x O DEFN: This field specifies the period of time during
which the goods are to be loaded on
(Narrative)
board/despatched/taken in charge.
RULE: For MT798<700>, if field 44C is used, field 44D
must not be used.
2.30 45A Description of Goods 100*65x O DEFN: his field contains a description of the goods
and/or Services and/or services.
(Narrative)
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 O DEFN: This field contains a description of any
documents required.
(Narrative)
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 O DEFN: This field contains a description of further
conditions of the documentary credit
(Narrative)
2.33 71B Charges 6*35x O DEFN: This field may be used only to specify charges
to be borne by the beneficiary.
(Narrative
RULE: For MT798<700> this field is not used.

17 December 2008 101


SWIFT for Corporates

2.34 48 Period for Presentation 4*35x O DEFN: This field specifies the period of time after the
date of shipment within which the documents must be
(Narrative)
presented for payment, acceptance or negotiation.
2.35 49 Confirmation Instructions 7!x M DEFN: This field contains confirmation instructions for
the Receiver.
(Instruction)
CODES: CONFIRM | MAY ADD | WITHOUT.
2.36 53a Reimbursing Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the name of the bank which
has been authorised by the Sender to reimburse
4!a2!a2!c[3!c] (Identifier Code)
drawings under the documentary credit. This may be a
D [/1!a][/34x] (Party Identifier) branch of the Sender or the Receiver, or an entirely
different bank.
4*35x (Name & Address)
RULE: For MT798<700> this field is not used.
2.37 78 Instructions to the 12*65x O DEFN: This field specifies instructions to the paying,
Paying/Accepting/Negotia accepting or negotiating bank. It may also indicate if
(Narrative)
ting Bank 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] (Party Identifier) O DEFN: This field identifies the bank, if different from
the Receiver, through which the documentary credit is
4!a2!a2!c[3!c] (Identifier Code)
to be advised/confirmed to the beneficiary.
C /34x (Party Identifier)
RULE: For MT798<700> this field is not used.
D [/1!a][/34x] (Party Identifier)
4*35x (Name & Address)
2.39 72 Sender to Receiver 6*35x O DEFN: This field specifies additional information for the
Information Receiver.
(Narrative)
RULE: For MT798<700> this field is not used.

102 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<701> - LC Application Extension


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<701> 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<701> the sub-message type must
have a fixed value of 701.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<701> the contents of this field are
specified in Section 2 that follows below.

17 December 2008 103


SWIFT for Corporates

Section 2 – Field 77E Structure [MT701]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the Application number
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 M DEFN: This field specifies the number of this message
in the series of messages sent for a documentary
(Number)(Total)
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 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the Sender.
RULE: For MT798<701> this field must specify a
documentary credit number, pre-assigned by the
applicant’s bank, or a fixed value of NONREF
2.5 45B Description of Goods 100*65x O DEFN: This field contains a description of the goods
and/or Services and/or services.
(Narrative)
2.6 46B Documents Required 100*65x O DEFN: This field contains a description of any
documents required.
(Narrative)
2.7 47B Additional Conditions 100*65x O DEFN: This field contains a description of further
conditions of the documentary credit.
(Narrative)

104 Standards MT Messages Implementation Guidelines


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: IRREVOCABLE


Documentary Credit Application Number: 7890123
Expiry Date: 30-Jul-07
Place of Expiry: Amsterdam
Amount: Euro 100,000
Debit Account 1234567891
Advising Bank: 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 Signed Commercial Invoice in Quintuplicate
through the Advising Bank:
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


SWIFT for Corporates

Information Flow

SWIFT Messages
SWIFT Message – 1 MT798 <770>
Explanation Format
Header
Sender ABCOBEB3
Message Type 798
Receiver OLBNK03L

Message text
Transaction reference number :20:B09290104112078T
Sub-message type :12:770
Proprietary message :77E:
:27A:1/2
:21A:7890123
:13E:200701151218
:24D: TELE
:53C: 1234567891
:71A:BEN
:29A:WILSON PICKET +3224567841

SWIFT Message – 2 MT798 <700>


Explanation Format
Header
Sender ABCOBEB3
Message Type 798
Receiver OLBNK03L

106 Standards MT Messages Implementation Guidelines


Trade Standards

Message text
Transaction reference number :20:B09290104112079T
Sub-message type :12:700
Proprietary message :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


SWIFT for Corporates

The following information comprises the documentary credit application:

Type of Credit: IRREVOCABLE


Documentary Credit Application Number: N66758
Expiry Date: 30 July 2007
Place of Expiry: Brussels
Amount: US Dollars 31,500
Available With: Advising Bank by acceptance of Beneficiary's
draft drawn at 30 days after bill of lading date on
Generale Bank
Shipment: 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

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 Standards MT Messages Implementation Guidelines


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 Format
Header
Sender SOLCORP3
Message Type 798
Receiver ESSESESS

Message text
Transaction reference number :20:Y067844451
Sub-message type :12:770

17 December 2008 109


SWIFT for Corporates

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

SWIFT Message – 2 MT798 <700>


Explanation Format
Header
Sender SOLCORP3
Message Type 798
Receiver ESSESESS

Message text
Transaction reference number :20:Y067844452
Sub-message type :12:700

110 Standards MT Messages Implementation Guidelines


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

SWIFT Message – 3 MT798 <701>


Explanation Format
Header
Sender SOLCORP3
Message Type 798
Receiver ESSESESS

Message text
Transaction reference number :20:Y067844453
Sub-message type :12:701

17 December 2008 111


SWIFT for Corporates

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

SWIFT Message – 4 MT798 <701>


Explanation Format
Header
Sender SOLCORP3
Message Type 798
Receiver ESSESESS

Message text
Transaction reference number :20:Y067844454
Sub-message type :12:701

112 Standards MT Messages Implementation Guidelines


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 Notification of Issuance of Documentary Credit


Scope

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 applicant’s 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


SWIFT for Corporates

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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<771> - LC Notification of Issuance Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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
[n*78x] (Text)
Receiver.
RULE: For MT798<771> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
total number of MT798 messages in the series.
RULE: For MT798<771> 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.

7 November 2008 115


SWIFT for Corporates

2.2 21A Customer Reference 16x M DEFN: This field specifies the related documentary
Number credit application number as received by the bank in
the original application from the corporate.
2.3 20 Documentary Credit 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 52a Issuing Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the issuing bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: When specified in option A, the identifier code
must be the SWIFT BIC8 or BIC11 of the issuing bank.
C /34x (Party Identifier)
2.6 58a Advising Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the advising bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: When specified in option A, the identifier code
must be the SWIFT BIC8 or BIC11 for the advising
D [/1!a][/34x] (Party Identifier)
bank.
4*35x (Name & Address)
2.7 29B Bank Contact 4*35x O DEFN: This field specifies the contact details of the
bank.
(Narrative)
2.8 72C Bank to Corporate 6*35x O DEFN: This field specifies additional information for the
Information corporate.
(Narrative)

MT 798<700> - LC Notification of Issuance Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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 Standards MT Messages Implementation Guidelines


Trade Standards

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<700> the sub-message type must
have a fixed value of 700.
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
[n*78x] (Text)
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. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the related documentary
Number 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


SWIFT for Corporates

MT 798<701> - LC Notification of Issuance Extension


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<701> 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<701> the sub-message type must
have a fixed value of 701.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<701> the contents of this field are
specified in Section 2 that follows below.

118 Standards MT Messages Implementation Guidelines


Trade Standards

Section 2 – Field 77E Structure [MT701]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the related documentary
Number 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


SWIFT for Corporates

5.1.3 Request for Amendment of Documentary Credit


Scope

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 applicant’s 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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<772> - LC Request for Amendment Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<772> 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<772> the sub-message type must
have a fixed value of 772.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<772> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the amendment reference
Number number which has been assigned by the corporate.

7 November 2008 121


SWIFT for Corporates

2.3 20 Documentary Credit 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 24D Method of Issue 4!c[/35x] M DEFN: This field specifies the method by which a
documentary credit amendment is to be issued.
(Method)(Additional Information)
CODES:
• TELE = Telecommunication/SWIFT
• PSTW = Post
• COUW = Courier
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 3!a M DEFN: This field specifies the party(s) responsible for
Charges Payable By the documentary credit amendment charges.
(Code)
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 O DEFN: This field specifies additional information for the
documentary credit charges.
(Narrative)
RULE: For MT798<772>, only used if field 71A 'Bank
Charges Payable By' is = OTH.
2.8 29A Customer Contact 4*35x O DEFN: This field specifies the contact details of the
corporate.
(Narrative)

122 Standards MT Messages Implementation Guidelines


Trade Standards

2.9 72C Corporate to Bank 6*35x O DEFN: This field specifies additional information for the
Information issuing bank.
(Narrative)

MT 798<707> - LC Request for Amendment Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<707> 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<707> the sub-message type must
have a fixed value of 707.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<707> the contents of this field are
specified in Section 2 that follows below.

7 November 2008 123


SWIFT for Corporates

Section 2 – Field 77E Structure [MT707]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the amendment reference
Number number which has been assigned by the corporate.
2.3 20 Sender's Reference 16x M 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] (Party Identifier) O DEFN: This field is used to identify the issuing bank,
when different from the Sender of the message.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<707> this field is not used.
C /34x (Party Identifier)
2.7 31C Date of Issue 6!n O DEFN: This field specifies the date of the original issue
of the documentary credit, ie, the date on which the
(Date)
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 O DEFN: This field specifies the date on which the
issuing bank considers the credit as being amended.
(Date)
RULE: For MT798<707> this field is not used.

124 Standards MT Messages Implementation Guidelines


Trade Standards

2.9 26E Number of Amendment 2n O DEFN: This field specifies the number which identifies
this amendment.
(Number)
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 [/34x] (Account M DEFN: This field specifies the party in favour of which
amendment) the documentary credit was issued, or transferred,
4*35x) (Name & Address)
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 O DEFN: This field specifies the new, ie, revised, expiry
date for presentation under the documentary credit.
(Date)
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 3!a15d O DEFN: This field contains the currency and amount of
Credit Amount an increase in the documentary credit amount.
(Currency)(Amount)
RULE: For MT798<707>, field 32B or field 33B must
be present, if field 34B used.
2.13 33B Decrease of 3!a15d O DEFN: This field contains the currency code and
Documentary Credit amount of a decrease in the documentary credit
(Currency)(Amount)
Amount amount.
RULE: For MT798<707>, field 32B or field 33B must
be present, if field 34B used.
2.14 34B New Documentary Credit 3!a15d O DEFN: This field contains the currency code and total
Amount After Amendment amount of the documentary credit after the
(Currency)(Amount)
amendment, disregarding any drawings.
RULE: For MT798<707>, if field 34B used, field 32B or
field 33B must be present.

7 November 2008 125


SWIFT for Corporates

2.15 39A Percentage Credit 2n/2n O DEFN: When the credit amount tolerance is being
Amount Tolerance amended, this field specifies the new tolerance relative
(Tolerance 1)(Tolerance 2)
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 Maximum Credit Amount 13x O DEFN: This field specifies the amended qualification of
the documentary credit amount.
(Code)
CODES: NOT EXCEEDING
RULE: For MT798<707>, if field 39B is used, field 39A
must not be used.
2.17 39C Additional Amounts 4*35x O DEFN: This field specifies amendments to any
Covered additional amounts covered, such as insurance,
(Narrative)
freight, interest, etc.
2.18 44A Place of Taking in 1*65x O DEFN: This field specifies amendments to the place of
Charge/Dispatch from taking in charge (in case of a multimodal transport
(Narrative)
.../Place of Receipt 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.
2.19 44E Port of Loading/Airport of 1*65x O DEFN: This field specifies amendments to the port of
Departure loading or airport of departure to be indicated on the
(Narrative)
transport document.
2.20 44F Port of Discharge/Airport 1*65x O DEFN: This field specifies amendments to the port of
of Destination discharge or airport of destination to be indicated on
(Narrative)
the transport document.
2.21 44B Place of Final 1*65x O DEFN: This field specifies amendments to the final
Destination/For destination or place of delivery to be indicated on the
(Narrative)
Transportation to .../Place transport document.
of Delivery

2.22 44C Latest Date of Shipment 6!n O DEFN: This field specifies amendments to the latest
date for loading on board/dispatch/taking in charge.
(Date)

126 Standards MT Messages Implementation Guidelines


Trade Standards

2.23 44D Shipment Period 6*65x O DEFN: This field specifies amendments to the period
of time during which the goods are to be loaded on
(Narrative)
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 O DEFN: This field specifies amendments to the
documentary credit for which there is no other specific
(Narrative)
field.
2.25 79 Narrative 35*50x O Second occurrence of field.79 (implemented in SR
2008).
(Narrative)
2.26 72 Sender to Receiver 6*35x O DEFN: This field specifies additional information for the
Information Receiver.
(Narrative)
RULE: For MT798<707> this field is not used.

7 November 2008 127


SWIFT for Corporates

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 Format
Header
Sender ESSESESS
Message Type 798
Receiver GEBABEBB

Message text
Transaction reference number :20:Y8967851
Sub-message type :12:772

128 Standards MT Messages Implementation Guidelines


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 Format
Header
Sender ESSESESS
Message Type 798
Receiver GEBABEBB

Message text
Transaction reference number :20:Y8967852
Sub-message type :12:707
Proprietary message :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

5.1.4 Notification of Amendment of Documentary Credit


Scope

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 applicant’s instruction received.
Usage

The series of MT798 messages for one Notification of Amendment must comprise:

7 November 2008 129


SWIFT for Corporates

• 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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<773> - LC Notification of Amendment Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<773> 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<773> the sub-message type must
have a fixed value of 773.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<773> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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


SWIFT for Corporates

2.2 21A Customer Reference 16x M DEFN: This field specifies the related documentary
Number credit amendment number as received by the bank in
the original application from the corporate.
2.3 20 Documentary Credit 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 29B Bank Contact 4*35x O DEFN: This field specifies the contact details of the
bank.
(Narrative)
2.6 72C Bank to Corporate 6*35x O DEFN: This field specifies additional information for the
Information corporate.
(Narrative)

MT 798<707> - LC Notification of Amendment Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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 Standards MT Messages Implementation Guidelines


Trade Standards

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
[n*78x] (Text)
Receiver.
RULE: For MT798<707> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT707]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the related documentary
Number credit amendment number as received by the bank in
the original application from the corporate.
2.3 MT707 Message M MT707 message contents.
RULE: For MT798<707> in field 20 (Sender's
Reference), this must specify the documentary credit
number.

7 November 2008 133


SWIFT for Corporates

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

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 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 Standards MT Messages Implementation Guidelines


Trade Standards

The following table indicates the composition of the transaction flows:

Export Documentary Credit


MT Sub- Status Max. Name Base
Message Message Occur Message
Type Type Type
Advice of Documentary Credit – B2C
MT798 774 M 1 LC Advice Index
MT798 700 M 1 LC Advice Details MT700
MT798 701 O 3 LC Advice Extension MT701
Advice of amendment of Documentary Credit – B2C
MT798 776 M 1 LC Amendment Index
MT798 707 M 1 LC Amendment Details MT707
Advice of Third Bank Documentary Credit – B2C
MT798 780 M 1 LC Third Bank Advice Index
MT798 710 M 1 LC Third Bank Advice Details MT710
MT798 711 O 3 LC Third Bank Advice Extension MT711
Advice of Transfer Documentary Credit – B2C
MT798 782 M 1 LC Transfer Advice Index
MT798 720 M 1 LC Transfer Advice Details MT720
MT798 721 O 3 LC Transfer Advice Extension MT721

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 Mandatory
O Optional
Usage Details DEFN Definition
RULE Usage Rule. Must be adhered to
GUID Usage Guidance. Recommended practice
CODE Applicable Code Values
NOTE Remark
Format a alphabetic, capital letters (A through Z), upper case
only
c alpha-numeric capital letters (upper case), and
digits only
n numeric, digits (0 through 9) only
x SWIFT X set:
• A to Z
• a to z
• 0 to 9
• / - ? : ( ) . , ’ + SPACE CrLf
! fixed length

7 November 2008 135


SWIFT for Corporates

d decimals, including decimal comma ',' preceding


the fractional part. The fractional part may be
missing, but the decimal comma must always be
present
Codes l or

5.2.1 Advice of Documentary Credit


Scope

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 45A + 46A Exceeds 9,800 characters
− MT701 47B
becomes
− MT700 45A

136 Standards MT Messages Implementation Guidelines


Trade Standards

− MT701 46B
− MT701 47B

Example 2.
− MT700 45A + 46A +47A Exceeds 9,800 characters
becomes
− MT700 45A
− MT701 46B
− MT701 47B

Example 3.
− MT700 45A
− MT701 46B + 47B Exceeds 9,800 characters
becomes
− MT700 45A
− MT701 46B
− MT701 47B

Example 4.
− MT700 45A Exceeds 9,800 characters
− MT701 46B + 47B Exceeds 9,800 characters
becomes
− MT700
− MT701 45B
− MT701 46B
− MT701 47B

7 November 2008 137


SWIFT for Corporates

MT 798<774> - LC Advice Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<774> 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<774> the sub-message type must
have a fixed value of 774.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<774> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
total number of MT798 messages in the series.
RULE: For MT798<774> 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.

138 Standards MT Messages Implementation Guidelines


Trade Standards

2.2 21P Advising Bank Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the advising bank to the
documentary credit.
2.3 20 Documentary Credit 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the issuing bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 31C Date of Issue 6!n M DEFN: This field specifies the date on which the
issuing bank considers the documentary credit as
(Date)
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.6 52a Issuing Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the bank which
issued the documentary credit.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<774>, when specified, the identifier
C /34x (Party Identifier)
code must be the SWIFT BIC8 or BIC11 for the issuing
bank.
2.7 58a Advising Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the bank which
is advising the documentary credit..
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<774>, when specified, the identifier
D [/1!a][/34x] (Party Identifier)
code must be the SWIFT BIC8 or BIC11 for the
4*35x (Name & Address) advising bank.
2.8 29A Advising Bank Contact 4*35x O DEFN: This field specifies the contact details of the
advising bank.
(Narrative)
2.9 21A Customer Reference 16x O DEFN: This field specifies the reference number which
Number has been assigned by the beneficiary to the
documentary credit.

7 November 2008 139


SWIFT for Corporates

2.10 49D Confirmation Indicator 7!x M DEFN: This field indicates whether documentary credit
has been confirmed.
(Instruction)
CODES:
CONFIRM = Confirmed
WITHOUT = Without confirmation
2.11 49F Confirmation Information 50*65x O DEFN: Additional information concerning confirmation
of the documentary credit advice.
(Narrative)
2.12 49G Charges Information 50*65x O DEFN: Additional information concerning billing.
(Narrative)
2.13 47E Information from Advising 100*65x O DEFN: Additional information from the advising bank
Bank related to the documentary credit advice.
(Narrative)

MT 798<700> - LC Advice Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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.
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<700> the sub-message type must
have a fixed value of 700.

140 Standards MT Messages Implementation Guidelines


Trade Standards

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
[n*78x] (Text)
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. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<701> 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.

7 November 2008 141


SWIFT for Corporates

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<701> the sub-message type must
have a fixed value of 701.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<701> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT701]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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 Standards MT Messages Implementation Guidelines


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 Amsterdam-
Rotterdam Bank, Rotterdam.

In addition to the above information, the documentary credit application is comprised of the
following:

Type of Credit: IRREVOCABLE


Documentary Credit Application Number: 7890123
Issuing Bank: ANZ Bank
Melbourne, Australia
Expiry Date: 30-Jul-07
Place of Expiry: Amsterdam
Amount: Euro 100,000
Debit Account 1234567891
Advising Bank: 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 Signed Commercial Invoice in Quintuplicate
through the Advising Bank:
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


SWIFT for Corporates

Information Flow

SWIFT Messages
SWIFT Message – 1 MT798 <774>
Explanation Format
Sender ARBNKN6L
Message Type 798
Receiver AMDCORP3
Message Text
Transaction reference number :20:G9975-98761
Sub-message type :12:774
Proprietary message :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

144 Standards MT Messages Implementation Guidelines


Trade Standards

SWIFT Message - 2 MT798 <700>


Explanation Format
Sender ARBNKN6L
Message Type 798
Receiver AMDCORP3
Message Text
Transaction reference number :20:G9975-98762
Sub-message type :12:700
Proprietary message :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

7 November 2008 145


SWIFT for Corporates

5.2.2 Advice of Amendment of Documentary Credit


Scope

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 series of MT798 messages for one advice must comprise:

• 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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<776> - LC Amendment Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<776> 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<776> the sub-message type must
have a fixed value of 776.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<776> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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


SWIFT for Corporates

2.2 21P Advising Bank Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the advising bank to the
documentary credit amendment.
2.3 20 Documentary Credit 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the issuing bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 31C Date of Issue 6!n M DEFN: This field specifies the date on which the
issuing bank considers the documentary credit as
(Date)
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.6 52a Issuing Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the bank which
issued the amendment.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<776>, when specified in option A,
C /34x (Party Identifier)
the identifier code must be the SWIFT BIC8 or BIC11
for the issuing bank.
2.7 58a Advising Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the bank which
is advising the amendment advice.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<776>, when specified in option A,
D [/1!a][/34x] (Party Identifier)
the identifier code must be the SWIFT BIC8 or BIC11
4*35x (Name & address) for the advising bank.

2.8 29A Advising Bank Contact 4*35x O DEFN: This field specifies the contact details of the
advising bank.
(Narrative)
2.9 21A Customer Reference 16x O DEFN: This field specifies the reference number which
Number has been assigned by the beneficiary to the
documentary credit.
2.10 49D Confirmation Indicator 7!x M DEFN: This field indicates whether amendment advice
has been confirmed.
(Instruction)
CODES: CONFIRM | WITHOUT.

148 Standards MT Messages Implementation Guidelines


Trade Standards

2.11 49F Confirmation Information 50*65x O DEFN: Additional information concerning confirmation
of the amendment advice.
(Narrative)
2.12 49G Charges Information 50*65x O DEFN: Additional information concerning bank
charges.
(Narrative)
2.13 47E Information from Advising 100*65x O DEFN: Additional information from the advising bank
Bank related to the amendment advice.
(Narrative)

MT 798<707> - LC Amendment Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<707> the contents of this field are
specified in Section 2 that follows below.

7 November 2008 149


SWIFT for Corporates

Section 2 – Field 77E Structure [MT707]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number has been assigned by the advising bank to the
documentary credit amendment.
2.3 MT707 Message M MT707 message contents.

150 Standards MT Messages Implementation Guidelines


Trade Standards

5.2.3 Advice of Third Bank Documentary Credit


Scope

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


SWIFT for Corporates

MT 798<780> - LC Third Bank Advice Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<780> 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<780> the sub-message type must
have a fixed value of 780.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<780> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
total number of MT798 messages in the series.
RULE: For MT798<780> 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 711s.

152 Standards MT Messages Implementation Guidelines


Trade Standards

2.2 21P Advising Bank Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the second advising bank to the
documentary credit.
2.3 20 Documentary Credit 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the issuing bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 31C Date of Issue 6!n M DEFN: This field specifies the date on which the
issuing bank considers the documentary credit as
(Date)
being issued.
GUID: MT798<780>This date must be the same as
the field 31C (Date of Issue) in the MT710.
2.6 52a Issuing Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the bank which
issued the documentary credit.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<780>, when specified in option A,
C /34x (Party Identifier)
the identifier code must be the SWIFT BIC8 or BIC11
for the issuing bank.
2.7 58a Advising Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the bank which
is advising the documentary credit to the beneficiary,
4!a2!a2!c[3!c] (Identifier Code)
i.e. the name of the second advising bank.
D /1!a][/34x] (Party Identifier)
RULE: For MT798<780>, when specified in option A,
4*35x (Name & Address) the identifier code must be the SWIFT BIC8 or BIC11
for the second advising bank.

2.8 29A Advising Bank Contact 4*35x O DEFN: This field specifies the contact details of the
second advising bank.
(Narrative)
2.9 56a First Advising Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the first
advising bank involved in processing the documentary
4!a2!a2!c[3!c] (Identifier Code)
credit.
C /34x (Party Identifier)
RULE: For MT798<780>, when specified in option A,
D [/1!a][/34x] (Party Identifier) the identifier code must be the SWIFT BIC8 or BIC11
for the first advising bank.
4*35x (Name & Address)

7 November 2008 153


SWIFT for Corporates

2.10 21B First Advising Bank 16x M DEFN: This field specifies the reference number which
Reference Number has been assigned by the first advising bank to the
documentary credit.
2.11 21A Customer Reference 16x O DEFN: This field specifies the reference number which
Number has been assigned by the beneficiary to the
documentary credit.
2.12 49D Confirmation Indicator 7!x M DEFN: This field indicates whether documentary credit
has been confirmed.
(Instruction)
CODES: CONFIRM | WITHOUT.
2.13 49F Confirmation Information 50*65x O DEFN: Additional information concerning confirmation
of the documentary credit advice.
(Narrative)
2.14 49G Charges Information 50*65x O DEFN: Additional information concerning bank
charges.
(Narrative)
2.15 47E Information from Advising 100*65x O DEFN: Additional information from the second advising
Bank bank related to the documentary credit advice.
(Narrative)

MT 798<710> - LC Third Bank Advice Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<710> 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<710> the sub-message type must
have a fixed value of 710.

154 Standards MT Messages Implementation Guidelines


Trade Standards

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
[n*78x] (Text)
Receiver.
RULE: For MT798<710> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT710]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<711> 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.

7 November 2008 155


SWIFT for Corporates

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<711> the sub-message type must
have a fixed value of 711.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<711> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT711]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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 Standards MT Messages Implementation Guidelines


Trade Standards

5.2.4 Advice of Transfer Documentary Credit


Scope

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 series of MT798 messages for one advice must comprise:

• 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


SWIFT for Corporates

MT 798<782> - LC Transfer Advice Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<782> 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<782> the sub-message type must
have a fixed value of 782.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<782> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 Standards MT Messages Implementation Guidelines


Trade Standards

2.2 21P Advising Bank Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the advising bank to the
documentary credit.
2.3 20 Documentary Credit 16x M DEFN: This field specifies the documentary credit
Number number which has been assigned by the issuing bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 31C Date of Issue 6!n M DEFN: This field specifies the date on which the
issuing bank considers the documentary credit as
(Date)
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.6 52a Issuing Bank A [/1!a][/34x] Party Identifier) M DEFN: This field specifies the name of the bank which
issued the documentary credit.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<782>, when specified in option A,
C /34x (Party Identifier)
the identifier code must be the SWIFT BIC8 or BIC11
for the issuing bank.
2.7 58a Advising Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the bank which
is advising the documentary credit.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<782>, when specified in option A,
D [/1!a][/34x] (Party Identifier)
the identifier code must be the SWIFT BIC8 or BIC11
4*35x (Name & Address) for the advising bank.
2.8 29A Advising Bank Contact 4*35x O DEFN: This field specifies the contact details of the
advising bank.
(Narrative)
2.9 55a Transferring Bank A [/1!a][/34x] (Party Identifier) M DEFN: This field specifies the name of the transferring
bank involved in processing the documentary credit.
4!a2!a2!c[3!c] (Identifier Code)
RULE: For MT798<782>, when specified in option A,
B [/1!a][/34x] (Party Identifier)
the identifier code must be the SWIFT BIC8 or BIC11
[35x] (Location) for the transferring bank.
D [/1!a][/34x] (Party Identifier)
4*35x (Name & Address)

7 November 2008 159


SWIFT for Corporates

2.10 21N Transferring Bank 16x M DEFN: This field specifies the reference number which
Reference Number has been assigned by the transferring bank to the
documentary credit.
2.11 21A Customer Reference 16x O DEFN: This field specifies the reference number which
Number has been assigned by the 2nd beneficiary to the
documentary credit.
2.12 49D Confirmation Indicator 7!x M DEFN: This field indicates whether documentary credit
has been confirmed.
(Instruction)
CODES: CONFIRM | WITHOUT.
2.13 49F Confirmation Information 50*65x O DEFN: Additional information concerning confirmation
of the documentary credit advice.
(Narrative)
2.14 49G Charges Information 50*65x O DEFN: Additional information concerning bank
charges.
(Narrative)
2.15 47E Information from Advising 100*65x O DEFN: Additional information from the advising bank
Bank related to the transferred documentary credit.
(Narrative)

MT 798<720> - LC Transfer Advice Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<720> 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<720> the sub-message type must
have a fixed value of 720.

160 Standards MT Messages Implementation Guidelines


Trade Standards

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
[n*78x] (Text)
Receiver.
RULE: For MT798<720> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT720]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<721> 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.

7 November 2008 161


SWIFT for Corporates

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<721> the sub-message type must
have a fixed value of 721.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<721> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT721]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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 Standards MT Messages Implementation Guidelines


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 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 the enveloped message should be adhered to, unless otherwise stated in this section of
the guide.

The following diagram depicts the transaction flows:

7 November 2008 163


SWIFT for Corporates

The following table indicates the composition of the transaction flows:

Guarantee / Standby Letter of Credit


MT Sub- Status Max. Name Base
Message Message Occur Message
Type Type Type
Application for issuance of Guarantee / Standby Letter of Credit – C2B
MT798 761 or M 1 Guarantee Application Index
784 M 1 Standby LC Application Index
MT798 760 M 1 Guarantee Request Details MT760
Notification of Guarantee / Standby Letter of Credit – B2C
MT798 762 or M 1 Guarantee Notification Index
785 M 1 Standby LC Notification Index
MT798 760 M 1 Guarantee Notification Details MT760
Request for amendment of Guarantee / Standby Letter of Credit – C2B
MT798 763 or M 1 Guarantee Amendment Request Index
786 M 1 Standby LC Amendment Request Index
MT798 767 M 1 Guarantee Amendment Request Details MT767
Notification of amendment of Guarantee / Standby Letter of Credit – B2C
MT798 764 or M 1 Guarantee Amendment Notification Index
787 M 1 Standby LC Amendment Notification Index
MT798 767 M 1 Guarantee Amendment Notification Details MT767
Advice of Reduction or Release – B2C
MT798 766 M 1 Advice of Release / Reduction Index
MT798 769 M 1 Advice of Release / Reduction Details MT769

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 Mandatory
O Optional
Usage Details DEFN Definition
RULE Usage Rule. Must be adhered to
GUID Usage Guidance. Recommended practice
CODE Applicable Code Values
NOTE Remark
Format a alphabetic, capital letters (A through Z), upper case
only
c alpha-numeric capital letters (upper case), and
digits only
n numeric, digits (0 through 9) only

164 Standards MT Messages Implementation Guidelines


Trade Standards

x SWIFT X set:
• A to Z
• a to z
• 0 to 9
• / - ? : ( ) . , ’ + SPACE CrLf
! fixed length
d decimals, including decimal comma ',' preceding
the fractional part. The fractional part may be
missing, but the decimal comma must always be
present
Codes l or

5.3.1 Application for Issuance of Guarantee / Standby Letter of


Credit
Scope

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


SWIFT for Corporates

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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<761> - Application for issuance of Guarantee Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<761> 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<761> the sub-message type must
have a fixed value of 761.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<761> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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


SWIFT for Corporates

2.2 21A Customer Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer.
2.3 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.4 22D Kind of Guarantee 4!c M DEFN: This field specifies the kind of the guarantee.
(Code) CODES:
GUAR = GUARANTEE
STLC = STANDBY LETTER OF CREDIT
SPDM = SURETY PAYABLE ON FIRST DEMAND
SURT = SURETY
2.5 22K Type of Guarantee 4!c[/35x] M DEFN: This field specifies the type of the guarantee.
(Type of Guarantee)(Narrative) 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 Standards MT Messages Implementation Guidelines


Trade Standards

2.6 22E Form of Guarantee 4!c M DEFN: This field specifies the form of the guarantee.
(Code) CODES:
DIRC = DIRECT
INDC = INDIRECT
2.7 22J Wording of Guarantee 4!c M DEFN: This field specifies the type of wording of the
guarantee.
(Code)
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 O DEFN: This field specifies any special terms that
should apply to the guarantee in case that the wording
(Code)
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 2!c O DEFN: This field specifies the language of the
Wording standard wording of the Issuing Bank, i.e. 2 alphabetic
(Code)
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 4*35x M DEFN: This field specifies the applicant for the
guarantee (i.e. the party considered by the issuing
(Name & Address)
bank to be the debtor / obligor).

7 November 2008 169


SWIFT for Corporates

2.11 50M Alternative Applicant 4*35x O DEFN: This field specifies the alternative applicant for
the guarantee (i.e. the party to be mentioned in the
(Name & Address)
Guarantee, if different to the Applicant specified in field
50).
2.12 12E Indicator of Alternative 4!c O This field indicates, in case that an Alternative
Beneficial Owner Applicant exists, whether the Applicant is acting on its
(Code)
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.13 39P Guarantee Amount 4!c/3!a15d M DEFN: This field specifies the type of guarantee
amount, the currency code of the amount and the
(Type)(Currency)(Amount)
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 / 4*35x O DEFN: This field specifies any additional amounts
Interest Covered covered by the guarantee in free text form, such as
(Narrative)
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 Standards MT Messages Implementation Guidelines


Trade Standards

2.15 23B Validity Type 4!c M DEFN: This field specifies whether the validity of the
guarantee is limited or unlimited.
(Type)
CODES: One of the following codes must be used:
LIMT = LIMITED
UNLM = UNLIMITED
2.16 31L Validity Expiry Date 6!n O DEFN: This field specifies the expiry date of the
guarantee.
(Date)
RULE: For MT798<761> this field may only be present
if field 23B contains code LIMT.

2.17 31S Approximate Expiry Date 6!n O DEFN: This field specifies the approximate expiry date
of the guarantee (unlimited validity), i.e. the economic
(Date)
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 O DEFN: This field specifies the expiry of the guarantee
in free text form, in cases that the expiry cannot be
(Narrative)
expressed as a date, e.g. 180 days after issuance of
guarantee.
2.19 23E Method of Transmission 4!c[/30x] O DEFN: This field specifies the method by which the
guarantee is to be transmitted to the Advising Bank, if
(Method)(Additional Information)
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.

7 November 2008 171


SWIFT for Corporates

2.20 24E Delivery of original 4!c[/30x] O DEFN: This field specifies the method by which the
guarantee original guarantee is to be delivered.
(Method)(Additional Information)
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 O DEFN: This field specifies to whom the original of the
Guarantee is to be delivered.
(Code)
CODES:
BENE = BENEFICIARY
APPL = APPLICANT
ALTA = ALTERNATIVE APPLICANT
SPEC = SPECIFIED ADDRESS
2.22 50B Delivery Address 4*35x O DEFN: This field specifies to whom the original of the
Guarantee is to be delivered.
(Name & Address)
RULE: For MT798<761> this field may only be used
when field 22G is SPEC.
2.23 53C Liability Account /34x O DEFN: This field specifies the number of the liability
account nominated by the Applicant.
(Account)
GUID: For MT798<761> for accounts serviced in
countries that have implemented IBAN, the IBAN
should be used to identify the account.

172 Standards MT Messages Implementation Guidelines


Trade Standards

2.24 25A Charges Account /34x O DEFN: This field specifies the number of account
nominated by the Applicant to be used for settlement
(Account)
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 M DEFN: This field specifies the party in favour of which
the guarantee is being issued.
4*35x) (Name & Address)
GUID: For MT798<761>, subfield account is not used.
2.26 52a Issuing Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the issuing bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: When specified in option A, the identifier code
must be the SWIFT BIC8 or BIC11 of the issuing bank.
D [/1!a][/34x] (Party Identifier)
RULE: For MT798<761>, this field may only be used
4*35x (Name & Address)
when field 22E consists of INDC (INDIRECT).
2.27 58a Advising Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the advising bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: When specified in option A, the identifier code
must be the SWIFT BIC8 or BIC11 for the advising
D [/1!a][/34x] (Party Identifier)
bank.
4*35x (Name & Address)
RULE: For MT798<761>, this field may only be used
when field 22E consists of DIRC (DIRECT).
2.28 49 Confirmation Indicator 7!x O DEFN: This field indicates whether the Advising Bank
is requested to add its confirmation to the advice of the
(Instruction)
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 M DEFN: This field specifies a brief description of the
guaranteed liability.
(Narrative)

7 November 2008 173


SWIFT for Corporates

2.30 20E Reference 4!c//35x O DEFN: This field defines a reference associated with
the guarantee.
(Code)(Reference)
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] O DEFN: This field specifies the date of the reference,
and optionally a secondary date.
(Date 1)(Date 2)
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 3!a15d O DEFN: This field specifies the currency and total
Amount amount of the order/contract.
(Currency)(Amount)
RULE: For MT798<761> the currency must be the
same currency as in field 39P (Guarantee Amount).
2.33 37J Guarantee Value in 12d O DEFN: This field specifies the guarantee value in
Percent percent in relation to the total order or contract value.
2.34 29A Customer Contact 4*35x O DEFN: This field specifies the contact details of the
corporate.
(Narrative)
2.35 29B Beneficiary Contact 4*35x O DEFN: This field specifies the contact details of the
beneficiary.
(Narrative)
2.36 72C Corporate to Bank 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

174 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<784> - Request for Standby LC Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<784> 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<784> the sub-message type must
have a fixed value of 784.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<784> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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


SWIFT for Corporates

2.2 21A Customer Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer.
2.3 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.4 40A Form of Credit 24x M DEFN: This field specifies the type of standby letter of
credit.
(Type)
CODES:
IRREVOCABLE STANDBY = Standby letter of credit is
irrevocable.
IRREVOC TRANS STANDBY = Standby letter of
credit is irrevocable
and transferable
2.5 50 Applicant 4*35x M DEFN: This is the party on whose behalf the standby
letter is issued.
(Name & Address)
2.6 50M Ultimate Obligor 4*35x O DEFN: This field specifies the party who is ultimately
obligated under the standby letter of credit, if different
(Name & Address)
from the Applicant.
2.7 33E Credit Amount 3!a15d M DEFN: This field specifies the currency code of the
amount and the amount of the standby letter of credit.
(Currency)(Amount)
2.8 39A Percentage Credit 2n/2n O DEFN: This field specifies the tolerance relative to the
Amount Tolerance standby letter of credit amount as a percentage plus
(Tolerance 1)(Tolerance 2)
(Tolerance 1) and/or minus (Tolerance 2) that amount.
RULE: MT798<784>, if field 39A is used, field 39B
must not be used.
2.9 39B Maximum Credit Amount 13x O 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 Validity Expiry Date 6!n M DEFN: This field specifies the expiry date of the
standby letter of credit.
(Date)

176 Standards MT Messages Implementation Guidelines


Trade Standards

2.11 35L Specification of Expiry 4*35x O DEFN: This field specifies the expiry of the standby
letter of credit in free text form, in cases that the expiry
(Narrative)
cannot be expressed as a date, e.g. 180 days after
issuance of a standby letter of credit.
2.12 23F Automatic Extension 4!c[/30x] O DEFN: This field specifies the requirement for a clause
Period covering an automatic extension of the validity expiry
(Code)(Additional Information)
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.13 38A Automatic Extension End 3n O DEFN: This field specifies the minimum number of
Notice Days calendar days for notice on non-extension to the
(Days)
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 6!n O DEFN: This field specifies the date after which the
Expiry Date credit will no longer be subject to automatic extension.
(Date)
RULE: For MT798<784> this field may only be present
if field 23F contains code ONEY or OTHR.
2.15 23E Method of Transmission 4!c[/30x] O DEFN: This field specifies the method by which the
standby letter of credit is to be transmitted to the
(Method)(Additional Information)
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


SWIFT for Corporates

2.16 24E Delivery of Original Credit 4!c[/30x] O DEFN: This field specifies the method by which the
original standby letter of credit is to be delivered.
(Method)(Additional Information)
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 O DEFN: This field specifies to whom the original of the
standby letter of credit is to be delivered.
(Code)
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 4*35x O DEFN: This field specifies to whom the original of the
Standby letter of credit is to be delivered.
(Name & Address)
RULE: For MT798<784> this field may only be used
when field 22G (Delivery to) is SPEC.
2.19 25A Charges Account /34x O DEFN: This field specifies the number of account
nominated by the applicant to be used for settlement
(Account)
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 Standards MT Messages Implementation Guidelines


Trade Standards

2.20 22P Drawing Mode 4!c[/4!c] O DEFN: This field specifies if multiple drawings are
allowed against the standby letter of credit
(Code)(Code)
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 M DEFN: This field specifies the documents and/or
instructions under which the payment will be made
(Narrative)
available to the beneficiary.
2.22 59 Beneficiary [/34x] (Account M DEFN: This field specifies the party in favour of which
the standby letter of credit is being issued.
4*35x) (Name & Address
GUID: For MT798<784>, subfield account is not used.
2.23 29B Beneficiary Contact 4*35x O DEFN: This field specifies the contact details of the
beneficiary.
(Narrative)
2.24 50N Secondary Credit 4*35x O DEFN: This field specifies the party in favour of which
Beneficiary a guarantee or undertaking is issued by the
(Name & Address)
beneficiary’s bank or correspondent based on the
standby letter of credit.
2.25 29C Secondary Credit Contact 35x O DEFN: This field specifies the contact name for the
Name party in favour of which a guarantee or undertaking is
issued by the beneficiary’s 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.

7 November 2008 179


SWIFT for Corporates

2.26 22K Secondary Credit Type 4!c[/35x] O DEFN: This field specifies the type of the bond,
guarantee or undertaking for a secondary credit.
(Type of Guarantee)(Narrative)
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 3!a15d O DEFN: This field specifies the currency code of the
Amount amount and the amount of the standby letter of credit.
(Currency)(Amount)
RULE: For MT798<784> this field may be present if
field 50N (Secondary Credit Beneficiary) is present.
2.28 31V Secondary Credit Validity 6!n O DEFN: This field specifies the expiry date of the
Expiry Date secondary standby letter of credit.
(Date)
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] (Party Identifier) O DEFN: This field specifies the issuing bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: MT798<784> When specified in option A, the
identifier code must be the SWIFT BIC8 or BIC11 of
D [/1!a][/34x] (Party Identifier)
the issuing bank.
4*35x (Name & Address)
2.30 58a Advising Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the advising bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: MT798<784> When specified in option A, the
identifier code must be the SWIFT BIC8 or BIC11 for
D [/1!a][/34x] (Party Identifier)
the advising bank.
4*35x (Name & Address)

180 Standards MT Messages Implementation Guidelines


Trade Standards

2.31 49 Confirmation Indicator 7!x O DEFN: This field indicates whether the Advising Bank
is requested to add its confirmation to the advice of the
(Instruction)
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 M DEFN: This field describes the purpose of the standby
letter of credit.
(Narrative)
2.33 29A Customer Contact 4*35x O DEFN: This field specifies the contact details of the
corporate.
(Narrative)
2.34 72C Corporate to Bank 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

MT 798<760> Application for issuance of Guarantee / Standby LC Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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


SWIFT for Corporates

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
[n*78x] (Text)
Receiver.
RULE: For MT798<760> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT760]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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 M DEFN: This field specifies the number of this message
in the series of messages sent for a guarantee, and
(Number)(Total)
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 16x M DEFN: This field contains a reference assigned by the
Number Sender to unambiguously identify the message.
RULE: For MT798<760> this field must specify a
guarantee / standby letter of credit number, pre-
assigned by the bank, or a fixed value of NONREF

182 Standards MT Messages Implementation Guidelines


Trade Standards

2.5 23 Further Identification 16x M DEFN: This field further identifies the purpose of the
message.
(Code)
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 O DEFN: When the message is sent to issue a
guarantee, this field specifies the issue date of the
(Date)
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] M DEFN: This field specifies the rules the guarantee is
subject to. Unless otherwise specified, it is also the
(Type)(Narrative)
rules the counter-guarantee is subject to.
CODES: ISPR | NONE | OTHR | URDG
2.8 77C Details of Guarantee 150*65x M DEFN: This field contains all terms, conditions and
details of the guarantee.
(Narrative)
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 Sender to Receiver 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)
RULE: For MT798<760> this field is not used

7 November 2008 183


SWIFT for Corporates

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 seller’s contact is John Sixpack and the reference number for this transaction is
XYZ999
Information Flow

SWIFT Messages
SWIFT Message – 1 MT798 <761>
Explanation Format
Sender PUMPCORP
Message Type 798
Receiver BOGEDEFFXXX
Message Text

184 Standards MT Messages Implementation Guidelines


Trade Standards

Transaction reference number :20:FGH96372


Sub-message type :12:761
Proprietary message :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 Format
Sender PUMPCORP
Message Type 798
Receiver BOGEDEFFXXX
Message Text
Transaction reference number :20:FGH96372
Sub-message type :12:760

7 November 2008 185


SWIFT for Corporates

Proprietary message :77E:


:27A:2/2
:21A:XYZ999
:27:1/1
:20:NONREF
:23:ISSUE
:40C:NONE
:77C:STANDARD WORDING

5.3.2 Notification of Guarantee / Standby Letter of Credit


Scope

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:

• 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
Usage

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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<762> - Notification of Guarantee Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<762> 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<762> the sub-message type must
have a fixed value of 762.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<762> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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


SWIFT for Corporates

2.2 21A Customer Reference 16x M DEFN: This field is used to specify the request
Number reference number as assigned by the corporate in the
initiating request.
2.3 20 Guarantee Number 16x M DEFN: This field specifies the reference number which
has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 39P Guarantee Amount 4!c/3!a15d M DEFN: This field specifies the type of guarantee
amount, the currency code of the amount and the
(Type)(Currency)(Amount)
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.6 23B Validity Type 4!c M DEFN: This field specifies whether the validity of the
guarantee is limited or unlimited.
(Type)
CODES: One of the following codes must be used:
LIMT = LIMITED
UNLM = UNLIMITED
2.7 31L Validity Expiry Date 6!n O DEFN: This field specifies the expiry date of the
guarantee.
(Date)
RULE: For MT798<762> this field may only be present
if field 23B contains code LIMT.
2.8 31S Approximate Expiry Date 6!n O DEFN: This field specifies the approximate expiry date
of the guarantee (unlimited validity), i.e. the economic
(Date)
maturity as per the underlying transaction.
RULE: For MT798<762> this field may only be present
if field 23B contains code UNLM.

188 Standards MT Messages Implementation Guidelines


Trade Standards

2.9 50 Applicant 4*35x M DEFN: This field specifies the applicant for the
guarantee (i.e. the party considered by the issuing
(Name & Address)
bank to be the debtor / obligor).
2.10 50M Alternative Applicant 4*35x O DEFN: This field specifies the alternative applicant for
the guarantee (i.e. the party to be mentioned in the
(Name & Address)
Guarantee, if different to the Applicant specified in field
50).
2.11 59 Beneficiary [/34x] (Account M DEFN: This field specifies the party in favour of which
the guarantee is being issued.
4*35x) (Name & Address)
GUID: For MT798<762>, subfield account is not used.
2.12 52a Issuing Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the issuing bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: When specified in option A, the identifier code
must be the SWIFT BIC8 or BIC11 of the issuing bank.
D [/1!a][/34x] (Party Identifier)
4*35x (Name & Address)
2.13 58a Advising Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the advising bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: When specified in option A, the identifier code
must be the SWIFT BIC8 or BIC11 for the advising
D [/1!a][/34x] (Party Identifier)
bank.
4*35x (Name & Address)
2.14 49H Special agreements 50*65x O DEFN: This field indicates any special agreements
between the Customer and the bank for the specified
(Narrative)
guarantee.
2.15 29B Bank Contact 4*35x O DEFN: This field specifies the contact details of the
bank
(Narrative)
2.16 72C Bank to Corporate 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

7 November 2008 189


SWIFT for Corporates

MT 798<785> - Notification of Standby LC Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<785> 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<785> the sub-message type must
have a fixed value of 785.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<785> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 Standards MT Messages Implementation Guidelines


Trade Standards

2.2 21A Customer Reference 16x M DEFN: This field is used to specify the request
Number reference number as assigned by the corporate in the
initiating request.
2.3 20 Credit Number 16x M DEFN: This field specifies the reference number which
has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 40A Form of Credit 24x M DEFN: This field specifies the type of standby letter of
credit.
(Type)
CODES:
IRREVOCABLE STANDBY = Standby letter of credit is
irrevocable.
IRREVOC TRANS STANDBY = Standby letter of
credit is irrevocable
and transferable
2.6 50 Applicant 4*35x M DEFN: This is the party on whose behalf the standby
letter is issued.
(Name & Address)
2.7 50M Ultimate Obligor 4*35x O DEFN: This field specifies the party who is ultimately
obligated under the standby letter of credit, if different
(Name & Address)
from the Applicant.
2.8 33E Credit Amount 3!a15d M DEFN: This field specifies the currency code of the
amount and the amount of the standby letter of credit.
(Currency)(Amount)
2.9 39A Percentage Credit 2n/2n O DEFN: This field specifies the tolerance relative to the
Amount Tolerance standby letter of credit amount as a percentage plus
(Tolerance 1)(Tolerance 2)
(Tolerance 1) and/or minus (Tolerance 2) that amount.
RULE: MT798<785>, if field 39A is used, field 39B
must not be used.
2.10 39B Maximum Credit Amount 13x O 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


SWIFT for Corporates

2.11 31L Validity Expiry Date 6!n M DEFN: This field specifies the expiry date of the
standby letter of credit.
(Date)
2.12 35L Specification of Expiry 4*35x O DEFN: This field specifies the expiry of the standby
letter of credit in free text form, in cases that the expiry
(Narrative)
cannot be expressed as a date, e.g. 180 days after
issuance of a standby letter of credit.
2.13 23F Automatic Extension 4!c[/30x] O DEFN: This field specifies the requirement for a clause
Period covering an automatic extension of the validity expiry
(Code)(Additional Information)
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.14 38A Automatic Extension End 3n O DEFN: This field specifies the minimum number of
Notice Days calendar days for notice on non-extension to the
(Days)
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 6!n O DEFN: This field specifies the date after which the
Expiry Date credit will no longer be subject to automatic extension.
(Date)
RULE: For MT798<785> this field may only be present
if field 23F contains code ONEY or OTHR.
2.16 23E Method of Transmission 4!c[/30x] O DEFN: This field specifies the method by which the
standby letter of credit is to be transmitted to the
(Method)(Additional Information)
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 Standards MT Messages Implementation Guidelines


Trade Standards

2.17 24E Delivery of Original Credit 4!c[/30x] O DEFN: This field specifies the method by which the
original standby letter of credit is to be delivered.
(Method)(Additional Information)
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 O DEFN: This field specifies to whom the original of the
standby letter of credit is to be delivered.
(Code)
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 4*35x O DEFN: This field specifies to whom the original of the
Standby letter of credit is to be delivered.
(Name & Address)
RULE: For MT798<785> this field may only be used
when field 22G (Delivery to) is SPEC.
2.20 25A Charges Account /34x O DEFN: This field specifies the number of account
nominated by the applicant to be used for settlement
(Account)
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


SWIFT for Corporates

2.21 22P Drawing Mode 4!c[/4!c] O DEFN: This field specifies if multiple drawings are
allowed against the standby letter of credit
(Code)(Code)
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 M DEFN: This field specifies the documents and/or
instructions under which the payment will be made
(Narrative)
available to the beneficiary.
2.23 59 Beneficiary [/34x] (Account M DEFN: This field specifies the party in favour of which
the standby letter of credit is being issued.
4*35x) (Name & Address)
GUID: For MT798<785>, subfield account is not used.
2.24 29B Beneficiary Contact 4*35x O DEFN: This field specifies the contact details of the
beneficiary.
(Narrative)
2.25 50N Secondary Credit 4*35x O DEFN: This field specifies the party in favour of which
Beneficiary a guarantee or undertaking is issued by the
(Name & Address)
beneficiary’s bank or correspondent based on the
standby letter of credit.
2.26 29C Secondary Credit Contact 35x O DEFN: This field specifies the contact name for the
Name party in favour of which a guarantee or undertaking is
issued by the beneficiary’s 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.

194 Standards MT Messages Implementation Guidelines


Trade Standards

2.27 22K Secondary Credit Type 4!c[/35x] O DEFN: This field specifies the type of the bond,
guarantee or undertaking for a secondary credit.
(Type of Guarantee)(Narrative)
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 3!a15d O DEFN: This field specifies the currency code of the
Amount amount and the amount of the standby letter of credit.
(Currency)(Amount)
RULE: For MT798<785> this field may be present if
field 50N (Secondary Credit Beneficiary) is present.
2.29 31V Secondary Credit Validity 6!n O DEFN: This field specifies the expiry date of the
Expiry Date secondary standby letter of credit.
(Date)
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] (Party Identifier) O DEFN: This field specifies the issuing bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: MT798<785> When specified in option A, the
identifier code must be the SWIFT BIC8 or BIC11 of
D [/1!a][/34x] (Party Identifier)
the issuing bank.
4*35x (Name & Address)
2.31 58a Advising Bank A [/1!a][/34x] (Party Identifier) O DEFN: This field specifies the advising bank.
4!a2!a2!c[3!c] (Identifier Code) RULE: MT798<785> When specified in option A, the
identifier code must be the SWIFT BIC8 or BIC11 for
D [/1!a][/34x] (Party Identifier)
the advising bank.
4*35x (Name & Address)

7 November 2008 195


SWIFT for Corporates

2.32 49 Confirmation Indicator 7!x O DEFN: This field indicates whether the Advising Bank
is requested to add its confirmation to the advice of the
(Instruction)
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 M DEFN: This field describes the purpose of the standby
letter of credit.
(Narrative)
2.34 29B Bank Contact 4*35x O DEFN: This field specifies the contact details of the
bank
(Narrative)
2.35 72C Bank to Corporate 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

MT 798<760> - Notification of Guarantee / Standby LC Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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.

196 Standards MT Messages Implementation Guidelines


Trade Standards

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
[n*78x] (Text)
Receiver.
RULE: For MT798<760> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT760]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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


SWIFT for Corporates

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
SELLER’s 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 Germany’s contact is Arthur Dent.

198 Standards MT Messages Implementation Guidelines


Trade Standards

Information Flow

SWIFT Messages
SWIFT Message – 1 MT798 <762>
Explanation Format
Sender BOGEDEFFXXX
Message Type 798
Receiver PUMPCORP
Message Text
Transaction reference number :20:BVC96372
Sub-message type :12:762
Proprietary message :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

7 November 2008 199


SWIFT for Corporates

SWIFT Message - 2 MT798 <760>


Explanation Format
Sender BOGEDEFFXXX
Message Type 798
Receiver PUMPCORP
Message Text
Transaction reference number :20:BVC96372
Sub-message type :12:760

200 Standards MT Messages Implementation Guidelines


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 SELLER’s
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


SWIFT for Corporates

5.3.3 Request for Amendment of Guarantee / Standby Letter of


Credit
Scope

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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<763> - Request for Amendment of Guarantee Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<763> 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<763> the sub-message type must
have a fixed value of 763.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<763> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer.

7 November 2008 203


SWIFT for Corporates

2.3 20 Guarantee Number 16x M DEFN: This field specifies the reference number which
has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 32B Increase of Guarantee 3!a15d O DEFN: This field contains the currency and amount of
Amount an increase in the Guarantee amount.
(Currency)(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.6 33B Decrease of Guarantee 3!a15d O DEFN: This field contains the currency code and
Amount amount of a decrease in the Guarantee amount.
(Currency)(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 O DEFN: This field specifies whether the amended
validity of the guarantee is limited or unlimited.
(Type)
CODES: One of the following codes must be used:
LIMT = LIMITED
UNLM = UNLIMITED
2.8 31L New Validity Expiry Date 6!n O DEFN: This field specifies the new expiry date of the
guarantee (limited validity) in case of an amendment.
(Date)
2.9 31S New Approximate Expiry 6!n O DEFN: This field specifies the new approximate expiry
Date date of the guarantee (unlimited validity) in case of an
(Date)
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.

204 Standards MT Messages Implementation Guidelines


Trade Standards

2.10 23E Method of Transmission 4!c[/35x] O DEFN: This field specifies the method by which the
amendment is to be transmitted to the Advising Bank,
(Method)(Additional Information)
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 4!c[/35x] O DEFN: This field specifies the method by which the
amendment original amendment is to be delivered..
(Method)(Additional Information)
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 O DEFN: This field specifies to whom the original of the
Guarantee amendment is to be delivered.
(Code)
CODES:
BENE = BENEFICIARY
APPL = APPLICANT
ALTA = ALTERNATIVE APPLICANT
SPEC = SPECIFIED ADDRESS

7 November 2008 205


SWIFT for Corporates

2.13 50B Delivery Address 4*35x O DEFN: This field specifies to whom the original of the
Guarantee amendment is to be delivered.
(Name & Address)
RULE: For MT798<763> this field may only be used
when field 22G is SPEC.
2.14 29A Customer Contact 4*35x O DEFN: This field specifies the contact details of the
corporate.
(Narrative)
2.15 72C Corporate to Bank 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

MT 798<786> - Request for Amendment of Standby LC Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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) M DEFN: This field is used to convey the message
contents in a format agreed to by the Sender and the
[n*78x] (Text)
Receiver.
RULE: For MT798<786> the contents of this field are
specified in Section 2 that follows below.

206 Standards MT Messages Implementation Guidelines


Trade Standards

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 21A Customer Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer.
2.3 20 Credit Number 16x M DEFN: This field specifies the reference number which
has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 32B Increase of Credit 3!a15d O DEFN: This field contains the currency and amount of
Amount an increase in the standby letter of credit amount.
(Currency)(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 3!a15d O DEFN: This field contains the currency code and
Amount amount of a decrease in the standby letter of credit
(Currency)(Amount)
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 2n/2n O DEFN: This field specifies the new tolerance relative to
Amount Tolerance the standby letter of credit amount as a percentage
(Tolerance 1)(Tolerance 2)
plus (Tolerance 1) and/or minus (Tolerance 2) that
amount.

7 November 2008 207


SWIFT for Corporates

2.8 31L New Validity Expiry Date E 6!n O DEFN: This field specifies the new expiry date of the
standby letter of credit in case of an amendment.
(Date)
2.9 35L New Specification of 4*35x O DEFN: This field specifies the expiry of the standby
Expiry letter of credit in free text form, in cases that the expiry
(Narrative)
cannot be expressed as a date, e.g. 180 days after
issuance of a standby letter of credit.
2.10 23F New Automatic Extension 4!c[/30x] O DEFN: This field specifies the requirement for a clause
Period covering an automatic extension of the validity expiry
(Code)(Additional Information)
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 38A New Automatic Extension 3n O DEFN: This field specifies the new minimum number of
End Notice Days calendar days for notice on non-extension to the
(Days)
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 6!n O DEFN: This field specifies the new date after which the
Final Expiry Date credit will no longer be subject to automatic extension.
(Date)
RULE: For MT798<786> this field may only be present
if field 23F contains code ONEY or OTHR.

208 Standards MT Messages Implementation Guidelines


Trade Standards

2.13 23E Method of Transmission 4!c[/35x] O DEFN: This field specifies the method by which the
amendment is to be transmitted to the Advising Bank,
(Method)(Additional Information)
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 Delivery of original 4!c[/35x] O DEFN: This field specifies the method by which the
amendment original standby letter of credit amendment is to be
(Method)(Additional Information)
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


SWIFT for Corporates

2.15 22G Delivery to 4!c O DEFN: This field specifies to whom the original of the
standby letter of credit amendment is to be delivered.
(Code)
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 4*35x O DEFN: This field specifies to whom the original of the
Standby letter of credit amendment is to be delivered.
(Name & Address)
RULE: For MT798<786> this field may only be used
when field 22G (Delivery to) is SPEC.
2.17 29A Customer Contact 4*35x O DEFN: This field specifies the contact details of the
corporate.
(Narrative)
2.18 72C Corporate to Bank 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

MT 798<767> - Request for Amendment of Guarantee / Standby LC Details


Section 1 – MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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 Standards MT Messages Implementation Guidelines


Trade Standards

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<767> the sub-message type must
have a fixed value of 767.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<767> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT767]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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 M DEFN: This field specifies the number of this message
in the series of messages sent for a guarantee, and
(Number)(Total)
the total number of messages in the series.
RULE: For MT798<767> this field is not validated by
the bank.

7 November 2008 211


SWIFT for Corporates

2.4 20 Transaction Reference 16x M DEFN: This field contains a reference assigned by the
Number 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 M 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 M DEFN: This field further identifies the purpose of the
message.
(Code)
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 O DEFN: When the message is sent to amend a
guarantee, this field specifies the date of the
(Date)
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 O DEFN: This field specifies the number which identifies
this amendment.
(Number)
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 Standards MT Messages Implementation Guidelines


Trade Standards

2.9 31C Date of Issue or Request 6!n M DEFN: When the message is sent to amend a
to Issue guarantee, this field must specify the original issue
(Date)
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 M DEFN: This field specifies all amended terms,
conditions and details of the guarantee.
(Narrative)
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 Sender to Receiver 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)
RULE: For MT798<767> the field is not used

7 November 2008 213


SWIFT for Corporates

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 Format
Sender PUMPCORP
Message Type 798
Receiver BOGEDEFFXXX
Message Text
Transaction reference number :20:TRE96372
Sub-message type :12:763

214 Standards MT Messages Implementation Guidelines


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 Format
Sender PUMPCORP
Message Type 798
Receiver BOGEDEFFXXX
Message Text
Transaction reference number :20:TRE96372
Sub-message type :12:767
Proprietary message :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

5.3.4 Notification of Amendment of Guarantee / Standby Letter of


Credit
Scope

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:

• 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
Usage

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


SWIFT for Corporates

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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<764> - Notification of Amendment of Guarantee LC Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<764> 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<764> the sub-message type must
have a fixed value of 764.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<764> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer.

7 November 2008 217


SWIFT for Corporates

2.3 20 Guarantee Number 16x M DEFN: This field specifies the reference number which
has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 32B Increase of Guarantee 3!a15d O DEFN: This field contains the currency and amount of
Amount an increase in the Guarantee amount.
(Currency)(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.6 33B Decrease of Guarantee 3!a15d O DEFN: This field contains the currency code and
Amount amount of a decrease in the Guarantee amount.
(Currency)(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 3!a15d O DEFN: This field contains the currency code and total
After Amendment amount of the Guarantee after the amendment.
(Currency)(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>, if field 34B used, field 32B or
field 33B must be present.

218 Standards MT Messages Implementation Guidelines


Trade Standards

2.8 23B New Validity Type 4!c O DEFN: This field specifies whether the amended
validity of the guarantee is limited or unlimited.
(Type)
CODES: One of the following codes must be used:
LIMT = LIMITED
UNLM = UNLIMITED

2.9 31L New Validity Expiry Date 6!n O DEFN: This field specifies the new expiry date of the
guarantee (limited validity) in case of an amendment.
(Date)
2.10 31S New Approximate Expiry 6!n O DEFN: This field specifies the new approximate expiry
Date date of the guarantee (unlimited validity) in case of an
(Date)
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.11 49H Special agreements 50*65x O DEFN: This field indicates any special agreements
between the Customer and the bank for the specified
(Narrative)
guarantee amendment.
2.12 29B Bank Contact 4*35x O DEFN: This field specifies the contact details of the
bank
(Narrative)
2.13 72C Bank to Corporate 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

MT 798<787> - Notification of Amendment of Standby LC Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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


SWIFT for Corporates

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<787> the sub-message type must
have a fixed value of 787.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<787> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 21A Customer Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer.
2.3 20 Credit Number 16x M DEFN: This field specifies the reference number which
has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.

220 Standards MT Messages Implementation Guidelines


Trade Standards

2.5 32B Increase of Credit 3!a15d O DEFN: This field contains the currency and amount of
Amount an increase in the standby letter of credit amount.
(Currency)(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 3!a15d O DEFN: This field contains the currency code and
Amount amount of a decrease in the standby letter of credit
(Currency)(Amount)
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 3!a15d O DEFN: This field contains the currency code and total
Amendment amount of the standby letter of credit after the
(Currency)(Amount)
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 2n/2n O DEFN: This field specifies the new tolerance relative to
Amount Tolerance the standby letter of credit amount as a percentage
(Tolerance 1)(Tolerance 2)
plus (Tolerance 1) and/or minus (Tolerance 2) that
amount.
2.9 31L New Validity Expiry Date E 6!n O DEFN: This field specifies the new expiry date of the
standby letter of credit in case of an amendment.
(Date)

7 November 2008 221


SWIFT for Corporates

2.10 35L New Specification of 4*35x O DEFN: This field specifies the expiry of the standby
Expiry letter of credit in free text form, in cases that the expiry
(Narrative)
cannot be expressed as a date, e.g. 180 days after
issuance of a standby letter of credit.
2.11 23F New Automatic Extension 4!c[/30x] O DEFN: This field specifies the requirement for a clause
Period covering an automatic extension of the validity expiry
(Code)(Additional Information)
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.12 38A New Automatic Extension 3n O DEFN: This field specifies the new minimum number of
End Notice Days calendar days for notice on non-extension to the
(Days)
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 6!n O DEFN: This field specifies the new date after which the
Final Expiry Date credit will no longer be subject to automatic extension.
(Date)
RULE: For MT798<786> this field may only be present
if field 23F contains code ONEY or OTHR.
2.14 23E Method of Transmission 4!c[/35x] O DEFN: This field specifies the method by which the
amendment is to be transmitted to the Advising Bank,
(Method)(Additional Information)
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 Standards MT Messages Implementation Guidelines


Trade Standards

2.15 24D Delivery of original 4!c[/35x] O DEFN: This field specifies the method by which the
amendment original standby letter of credit amendment is to be
(Method)(Additional Information)
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 O DEFN: This field specifies to whom the original of the
standby letter of credit amendment is to be delivered.
(Code)
CODES:
BENE = BENEFICIARY
APPL = APPLICANT
OBLG = ULTIMATE OBLIGOR
SPEC = SPECIFIED ADDRESS
2.17 50B Delivery Address 4*35x O DEFN: This field specifies to whom the original of the
standby letter of credit amendment is to be delivered.
(Name & Address)
RULE: For MT798<786> this field may only be used
when field 22G (Delivery to) is SPEC.
2.18 29B Bank Contact 4*35x O DEFN: This field specifies the contact details of the
bank
(Narrative)
2.19 72C Bank to Corporate 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

7 November 2008 223


SWIFT for Corporates

MT 798<767> - Notification of Amendment of Guarantee / Standby LC Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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.
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<767> the sub-message type must
have a fixed value of 767.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<767> the contents of this field are
specified in Section 2 that follows below.

224 Standards MT Messages Implementation Guidelines


Trade Standards

Section 2 – Field 77E Structure [MT767]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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


SWIFT for Corporates

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 Format
Sender BOGEDEFFXXX

226 Standards MT Messages Implementation Guidelines


Trade Standards

Message Type 798


Receiver PUMPCORP
Message Text
Transaction reference number :20:KLM96372
Sub-message type :12:764
Proprietary message :77E:
:27A:1/2
:21A:XYZ999
:20:PGFFA0815
:13E:200806221033
:31L:090630:

SWIFT Message - 2 MT798 <767>


Explanation Format
Sender BOGEDEFFXXX
Message Type 798
Receiver PUMPCORP
Message Text
Transaction reference number :20:BVC96372
Sub-message type :12:767
Proprietary message :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.

5.3.5 Advice of Reduction or Release


Scope

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


SWIFT for Corporates

• 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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<766> - Advice of Reduction or Release Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<766> 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<766> the sub-message type must
have a fixed value of 766.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<766> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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


SWIFT for Corporates

2.2 21A Customer Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer or a fixed value of
NONREF (e.g. in cases where no reference is
available).
2.3 20 Guarantee/Credit Number 16x M DEFN: This field specifies the reference number which
has been assigned by the bank.
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 29B Bank Contact 4*35x O DEFN: This field specifies the contact details of the
bank
(Narrative)
2.6 72C Bank to Corporate 6*35x O DEFN: This field contains additional information for the
Information Receiver.
(Narrative)

MT 798<769> - Advice of Reduction or Release Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<769> 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<769> the sub-message type must
have a fixed value of 769.

230 Standards MT Messages Implementation Guidelines


Trade Standards

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
[n*78x] (Text)
Receiver.
RULE: For MT798<769> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT769]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number 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 Field Name
25 Account Identification
32a Amount of Charges
57a Account With Bank
71B Details of Charges

7 November 2008 231


SWIFT for Corporates

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 Format
Sender BOGEDEFFXXX
Message Type 798
Receiver PUMPCORP
Message Text
Transaction reference number :20:DAS96372
Sub-message type :12:766
Proprietary message :77E:
:27A:1/2
:21A:XYZ999
:20:PGFFA0815
:13E:200807101145

232 Standards MT Messages Implementation Guidelines


Trade Standards

SWIFT Message - 2 MT798 <769>


Explanation Format
Sender BOGEDEFFXXX
Message Type 798
Receiver PUMPCORP
Message Text
Transaction reference number :20:DAS96372
Sub-message type :12:769
Proprietary message :77E:
:27A:2/2
:21A:XYZ999
:20:PGFFA0815
:21:NONREF
:30:080710
:33B:EUR50000,
:34B:0,

7 November 2008 233


SWIFT for Corporates

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 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 the enveloped message should be adhered to, unless otherwise stated in this section of
the guide.

The following diagram depicts the transaction flows:

The following table indicates the composition of the transaction flows:

MT Sub- Status Max. Name Base


Message Message Occur Message
Type Type Type
Free Format Message – C2B
MT798 788 M 1 Free Format Message Index
MT798 799 M 1 Free Format Message Details MT799
Free Format Message – B2C
MT798 789 M 1 Free Format Message Index
MT798 799 M 1 Free Format Message Details MT799

234 Standards MT Messages Implementation Guidelines


Trade Standards

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 Mandatory
O Optional
Usage Details DEFN Definition
RULE Usage Rule. Must be adhered to
GUID Usage Guidance. Recommended practice
CODE Applicable Code Values
NOTE Remark
Format a alphabetic, capital letters (A through Z), upper case
only
c alpha-numeric capital letters (upper case), and
digits only
n numeric, digits (0 through 9) only
x SWIFT X set:
• A to Z
• a to z
• 0 to 9
• / - ? : ( ) . , ’ + SPACE CrLf
! fixed length
d decimals, including decimal comma ',' preceding
the fractional part. The fractional part may be
missing, but the decimal comma must always be
present
Codes l or

5.4.1 Free Format Message - Corporate-to-Bank


Scope

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


SWIFT for Corporates

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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<788> - Free Format Message - Corporate-to-Bank Index


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number the Sender to unambiguously identify the message.
GUID: For MT798<788> 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<788> 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
[n*78x] (Text)
Receiver.
RULE: For MT798<788> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer.

7 November 2008 237


SWIFT for Corporates

2.3 21R Bank Reference Number 16x M DEFN: This field specifies the reference number of the
bank (i.e. Documentary Credit Number or Guarantee
Number).
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 29A Customer Contact 4*35x O DEFN: This field specifies the contact details of the
corporate.
(Narrative)
2.6 72C Corporate to Bank 6*35x O DEFN: This field specifies additional information for the
Information recipient.
(Narrative)

MT 798<799> - Free Format Message - Corporate-to-Bank Details


Section 1 - MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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.
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
[n*78x] (Text)
Receiver.
RULE: For MT798<799> the contents of this field are
specified in Section 2 that follows below.

238 Standards MT Messages Implementation Guidelines


Trade Standards

Section 2 – Field 77E Structure [MT799]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer.
NOTE: This field is not present in the MT799 Message
Reference Guide.
2.3 20 Transaction Reference 16x M DEFN: This field specifies the reference number of the
Number 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 16x O DEFN: This field contains a reference number to the
Number related message.
RULE: For MT798<799> This field is not used.
2.5 79 Narrative 35*50x M DEFN: This field contains the free format message.
(Narrative)

7 November 2008 239


SWIFT for Corporates

5.4.2 Free Format Message - Bank-to-Corporate


Scope

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 Standards MT Messages Implementation Guidelines


Trade Standards

MT 798<789> - Free Format Message - Bank-to-Corporate Index


Section 1 – MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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
[n*78x] (Text)
Receiver.
RULE: For MT798<789> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [Proprietary Message]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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


SWIFT for Corporates

2.2 21A Customer Reference 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer or a fixed value of
NONREF (e.g. in cases where no reference is
available).
2.3 21R Bank Reference Number 16x M DEFN: This field specifies the reference number of the
bank (i.e. Documentary Credit Number or Guarantee
Number).
2.4 13E Message Creation Date 8!n4!n M DEFN: Date and time at which the message was
Time created. Date format YYYYMMDD. Time format:
(Date)(Time)
HHMM.
2.5 29B Bank Contact 4*35x O DEFN: This field specifies the contact details of the
bank.
(Narrative)
2.6 72C Bank to Corporate 6*35x O DEFN: This field specifies additional information for the
Information recipient.
(Narrative)

MT 798<799> - Free Format Message - Bank-to-Corporate Details


Section 1 – MT798 Structure
No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
1.1 20 Transaction Reference 16x M DEFN: This field specifies the reference assigned by
Number 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 Standards MT Messages Implementation Guidelines


Trade Standards

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
[n*78x] (Text)
Receiver.
RULE: For MT798<799> the contents of this field are
specified in Section 2 that follows below.

Section 2 – Field 77E Structure [MT799]


No. Tag Field Name Format Status Definition / Content / Additional Usage
Rules/Guidelines
2.1 27A Message Index/Total 1!n/1!n M DEFN: This field specifies the sequence number of this
message in the series of MT798 messages and the
(Message Index)/(Total)
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 16x M DEFN: This field specifies the reference number which
Number has been assigned by the customer or a fixed value of
NONREF (e.g. in cases where no reference is
available).
2.3 20 Transaction Reference 16x M DEFN: This field specifies the reference number of the
Number 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 16x O DEFN: This field contains a reference number to the
Number related message.
RULE: For MT798<799> This field is not used.
2.5 79 Narrative 35*50x M DEFN: This field contains the free format message.
(Narrative)

7 November 2008 243


SWIFT for Corporates

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 Standards MT Messages Implementation Guidelines

You might also like