Amendment by MT799 (free format SWIFT)

[Shahed]

The L/C was issued by MT 700 and subsequently issuing bank would like to change the payment terms and send a MT 799 to advising bank quoting the L/C number only (without mentioning the word "amendment") on the message.

Can we consider this message as an integral part of the L/C ?

Shahed
Toronto

[RolandLeupi]

Depend what has changed. Is it a rectification, changing the name of the reimbursing bank for ex., or is it an effective change, payable by deferred payment at 30 days instead of at sight for ex.
If it falls under the second possibility I would like to see anywhere on the message the word "amendment" or within a sentence "we herewith amend"

[Shahed]

Through MT799, issuing bank requesting advising bank/confirming bank to pay beneficiary at sight and undertake to reimburse the advising/confirming bank after 30 days of the payment to beneficiary.

Can we consider MT 799 as an integral part of L/C ?

Shahed
Toronto
[edited 9/12/2007 8:29:46 PM]

[POLTERD.]

Dear Shahed,
MT799 is normally used to send or receive information for which another message type isn't applicable. Anyhow,banks are often using MT799 in order to transmit amendments.
In my opinion, if the issuing bank clearly states that the MT799 wording is replacing the paym.instructions stated under MT700, is ok and there is no need for word "amendment" to appear.
Anyhow,the MT799 you received is to be consider as an integral part of l/c (is sent under a specific l/c reference no.) but you now must see if its wording satisfy you or not.If something remains unclear you must urgently clarify.
Regards,
Bogdan

[vobrien]

I think the real question is whether the MT799 message can be considered as binding on the issuing bank as an amendment to credit as originally issued.

I do not consider the use of a label ‘amendment’ as paramount but of course it adds clarity.

If the MT799 clearly references the LC issued and if that message amends terms and conditions of the credit as issued then the issuing bank is irrevocably bound by the message/amendment as of the time it issues this message/amendment.

This then becomes an integral part of the credit.

This comment is made notwithstanding the fact that a credit can not be amended or cancelled without also having the agreement of the confirming bank, if any, and of course the beneficiary.

[PaulMiserez]

1) SWIFT cannot support the practice of using MT 799s for communication in lieu of an existing message type, in this case the MT 707 (LC amendment).
2) As someone correctly stated, if a specific message type exists (MT 707), then this one should be used. The scope of the MT 799 says that it is used "... to send or receive information for which another message type is not applicable". Going against this may mean that you are in violation with SWIFT standards policies.
3) The scope of the MT 707 says indeed that "the amendment is to be considered as part of the documentary credit". I would personally not feel comfortable with an MT 799 that does not say this, nor one that is silent about the fact that it is an LC amendment.

[vobrien]

Thanks Paul.

SWIFT cannot support this practice and I don’t support it either - but it happens.

Using SWIFT message types for the reason they were created is the right thing to do.

Clearly when a bank issues an amendment the correct message type should be used and it makes sense for SWIFT to support and to encourage banks to use the correct message type MT707.

This is good advice but quite often banks or people don’t do the right thing and I guess we are discussing particular implications.

From LC perspective I think the key and central questions remains as to whether such a MT799 message amends the credit and binds the bank that issued the message accordingly.

By way of simple example lets consider an MT 799 having been issued referring specifically to an earlier issued MT700 , the credit amount etc and stating that by way of this simple example
‘expiry date extended to 30 September 2007 and Latest Shipment Date extended to 10 September 2007’.

In this instance is the Issuing bank irrevocably bound by that said message amending the expiry date and latest shipment date?

Is the Issuing banks definite undertaking to honour now extended to 30 September 2007?

Vin


[edited 9/18/2007 2:43:39 PM]

[SvetlanaS]

As a beneficiary we receive amendments to Standby’ LC’s by means of covering letter from local confirming bank sometimes attaching a copy MT 799 which states the expiry date has been extended to a new expiry date.

The confirming bank in their covering letter attached to the MT 799 state that they have agreed and extend their confirmation to the new expiry date of the Standby LC.

Our understanding is that the issuing bank has amended the LC and now the confirming bank has confirmer’s obligation to honour a complying presentation up to the new extended LC expiry date.

This is despite the fact that in context the beneficiary the LC remains unamended until we communicate our acceptance of the amendment.

[POLTERD.]

Dear Vin,
UCP600 (art.10b) clearly states that iss.bank is irrevocably bound as of the time it issues the amendment. There is no reference to how the amendment has been issued/tranmsmitted.
UCP600 art.11a states "an authenticated teletransmission of a credit or amendment will be deemed to be the operative credit or amendment..." .
"Authenticated teletransmission" doesnt' mean MT707 only, but only exclude MT999. MT799 is also an authenticated mssg.
Of course,to receive a MT707 would be the best but when a MT799 is received you have to accept it as an amendment as long as it is clear and beyond any doubt that is an amendment.
Either using words like "pls delete:.../pls insert:..." or "pls read...instead of...." or "replace...with...." or any such words wich signify an amendment.
Word "amendment" need not be stated.
Best regards,
Bogdan

[vobrien]

Dear Bogdan

Your post is not 'identical' but does not 'conflict' with my post of 13 September above.

I think this will give some comfort to comment from Svetlana above.

And yes, best to use correct message type as supported by Paul.

Vin
[edited 9/19/2007 10:07:46 AM]