MT767 Amendment to a Demand Guarantee / Standby Letter of Credit

When MT767 is used

Guarantees change during their life. The contract is delayed, so the expiry date moves. Part of an advance is repaid, so the amount comes down. The parties agree to release the guarantee early. In each case the applicant asks its bank, the issuer, to amend the guarantee, and the issuer sends an MT767 to the bank that advised it. That bank passes the amendment on to the beneficiary, with its own MT767 (purpose ADVA or ACNA) when another bank sits further down the chain.

An amendment is not binding on the beneficiary until the beneficiary agrees to it: both URDG 758 and ISP98 work this way. So every MT767 is followed by an answer. The beneficiary, or the advising bank on its behalf, reports acceptance or rejection in an MT787. The MT767 itself only proposes the change. Until the answer arrives the issuer still carries the original terms in its books.

The layout mirrors the MT760 since November 2021. Sequence A says what the message is (22A) and whether it is a request to cancel (23S CANCEL). Sequence B identifies the undertaking by number (20), the amendment by number (26E) and date (30), and carries the coded changes: an increase (32B) or decrease (33B) of the amount, a new expiry type or date (23B, 31E, 35G), a new beneficiary (59a), and everything else in narrative field 77U. Sequence C does the same for the local undertaking when the original MT760 was a counter-guarantee (ISCO or ICCO).

Only what changes is sent. Terms that the MT767 does not mention stay as they were, so 77U should describe the change (“the expiry date is extended to...”, “clause 4 is replaced by...”) rather than restate the whole guarantee. When the changed text is too long for one message it continues in one or more MT775 messages under the same undertaking and amendment numbers.

Related messages: the MT768 acknowledges a guarantee message, the MT769 advises a reduction or release (for example when the issuer is told it is no longer liable), the MT785 gives notice that an automatically extending guarantee will not be extended, and the MT765 carries a demand for payment, which can be an “extend or pay” request that leads to an MT767 extending the expiry.

MT767 format: sequences and fields

Rules worth knowing

• Field 23 (Advising Bank Reference) may be present only when 22A is ADVA or ACNA.
• When 22A is ISCA or ICCA, fields 24E and 24G are not allowed in sequence B (rule added in the November 2023 release). Delivery instructions for the local undertaking go in sequence C.
• An amendment to an MT760 with 22A ISSU is sent with ISUA and has sequences A and B only. An amendment to an ISCO or ICCO is sent with ISCA or ICCA and may carry sequence C. A purpose code that does not match the original issue is a reason for the receiver to stop the message.
• 32B and 33B are the change in amount, not the new amount. Receivers recalculate the outstanding amount themselves, so a wrong figure here leads straight to a reconciliation break.
• Long amendments continue in one or more MT775 messages numbered in field 27. Information in a designated field of the MT767 must not be repeated in the MT775.
• An amendment binds the beneficiary only once it accepts it, and partial acceptance is generally treated as rejection. The response comes back in an MT787 quoting the undertaking number and the amendment number in 26E.

MT767 example

Five months after issuing the advance payment guarantee ZTG2610200007 (see the MT760 example), ZagTrader Test Bank (ZAGTAEADXXX) amends it at the request of Northwind Engineering LLC: the contractor has repaid EUR 500,000.00 of the advance through its invoices, and the depot is running late, so the expiry moves from 31 December 2027 to 30 June 2028. The issuer sends amendment number 1 to the advising bank BANKGB2LXXX, quoting the advising bank’s own reference ADV26G00441 in field 21.

{1:F01ZAGTAEADAXXX0000000000}{2:I767BANKGB2LXXXXN}{4:
:15A:
:27:1/1
:21:ADV26G00441
:22A:ISUA
:15B:
:20:ZTG2610200007
:26E:1
:30:270315
:52A:ZAGTAEADXXX
:33B:EUR500000,00
:23B:FIXD
:31E:280630
:77U:THE AMOUNT IS REDUCED FOLLOWING REPAYMENT OF EUR 500,000.00 OF
THE ADVANCE PAYMENT. ALL OTHER TERMS AND CONDITIONS REMAIN
UNCHANGED. PLEASE OBTAIN AND ADVISE US OF THE BENEFICIARY
ACCEPTANCE OR REJECTION OF THIS AMENDMENT.
-}

Line by line

The BICs, names and references are made up.

BANKGB2LXXX advises the amendment to Harbour Rail Systems Ltd and, once the beneficiary has answered, sends an MT787 to ZAGTAEADXXX with the acceptance or rejection of amendment 1.

A cancellation request would add :23S:CANCEL in sequence A, and 77U would typically ask the beneficiary to confirm release and return any paper original.

Common errors and rejects

1. Advising bank reference with the wrong purpose code

   Field 23 was sent with 22A ISUA. It is allowed only when an advising bank passes the amendment on (ADVA or ACNA). The issuer quotes the advising bank’s reference in field 21 instead.

2. Delivery fields in sequence B of a counter-guarantee amendment

   With 22A ISCA or ICCA, 24E and 24G may not appear in sequence B. Move delivery instructions for the local undertaking into sequence C.

3. Purpose code does not match the original issue

   An ISCA was sent for a guarantee that was issued with ISSU, or an ISUA for a counter-guarantee. Receivers check this against the original MT760 and hold the message. Use ISUA for ISSU, ISCA for ISCO and ICCA for ICCO.

4. Amendment number out of sequence

   26E skips a number or repeats one already received. The receiver cannot tell whether an amendment is missing and will query before advising. Number amendments consecutively per undertaking, including amendments that were later rejected.

5. New total amount sent as an increase or decrease

   The new outstanding amount (for example EUR 1,000,000.00) was put in 33B instead of the decrease (EUR 500,000.00). The receiver then reduces the guarantee by the wrong amount. 32B and 33B always carry the change.

6. Old pre-2021 layout

   Templates that still produce the old MT767 (one narrative field 77C with the amendment details and a free 23 Further Identification) fail validation since 21 November 2021. Use the sequence layout with 15A, 15B, 22A, 26E, 30 and 52a.

MT767 in ISO 20022

Swift’s MT and MX equivalence table (May 2024) lists tsrv.005 UndertakingAmendment as the ISO 20022 equivalent of the MT767. The same table lists no equivalent for the continuation MT775 or for the amendment response MT787.

An equivalent in the standard is not the same as use on the network. Guarantee and standby messages in category 7 were not part of the November 2025 payments migration, and banks still exchange amendments as MT767 and MT775.

Related messages

• MT760Issue of a Demand Guarantee / Standby Letter of Credit
• MT775Amendment to a Demand Guarantee / Standby Letter of Credit
• MT787Guarantee / Standby Letter of Credit Amendment Response
• MT768Acknowledgement of a Guarantee / Standby Message
• MT769Advice of Reduction or Release
• MT707Amendment to a Documentary Credit
• MT799Free Format Message

MT767 questions

What is an MT767?

It is the Swift message used to amend a demand guarantee or standby letter of credit that was issued with an MT760, or to request its cancellation. The issuer sends it to the advising bank, which passes the change on to the beneficiary.

What is the difference between MT767 and MT707?

Both amend an instrument issued earlier. The MT707 amends a documentary credit issued with an MT700; the MT767 amends a guarantee or standby issued with an MT760. Their continuation messages are the MT708 and the MT775.

How is a guarantee cancelled by Swift?

The issuer sends an MT767 with :23S:CANCEL in sequence A. The cancellation takes effect when the beneficiary agrees, and the answer comes back in an MT787. A guarantee can also end by expiry, by return of the original, or by a release advised in an MT769.

What are MT775 and MT787?

The MT775 is the continuation of an MT767 when the amendment text is too long for one message. The MT787 is the response to an amendment: it tells the issuer whether the beneficiary accepted or rejected it.

Does the beneficiary have to accept an MT767 amendment?

Under URDG 758 and ISP98 an amendment does not bind the beneficiary without its consent, so the issuer stays liable on the earlier terms until acceptance is reported. Accepting only part of an amendment counts as a rejection.