MT 765: Guarantee/Standby Letter of Credit Demand — Deterministic Compliance Architecture

Introduction

The MT 765 Guarantee/Standby Letter of Credit Demand is the SWIFT message that converts a dormant standby obligation into a live payment claim. It is the single most consequential message in the guarantee lifecycle — the point where the beneficiary's right to draw becomes an executed demand that the issuing bank must either honour, extend, or dishonour within a binary window. Every field in the MT 765 is either compliant or discrepant. There is no partial compliance.

The illusion is that a standby demand is a formality — that the beneficiary simply issues a payment request and the bank pays. The failure mode is systemic: an MT 765 with a malformed demand type code, a missing narrative, an amount that exceeds the available balance, or a demand statement coded as incomplete when no further documentation follows will mutate a valid claim into a discrepant presentation. The issuing bank then applies its examination obligation under ISP98 Rule 5.01, dishes the demand, and the beneficiary loses its payment window. The demand itself becomes the discrepancy.

This guide isolates the three dominant failure modes in MT 765 construction and provides a deterministic resolution architecture for each.

Failure Mode Analysis

Failure Mode 1: Demand Type / Narrative Mismatch

The beneficiary submits an MT 765 with Field 21M coded as PAYM (Pay Only) when the standby requires an extend-or-pay demand. The issuing bank receives the demand, examines it against the standby terms, and determines that the demand type does not comply with the undertaking's requirements. The bank dishes the demand under ISP98 Rule 5.02 — "A notice of dishonour shall state all discrepancies upon which dishonour is based."

Root cause: The beneficiary's SWIFT operator misreads the standby's demand provisions. The standby may state: "This standby shall automatically extend for successive periods of one year each unless the beneficiary notifies the issuer at least 30 days before the current expiry date of its intention not to extend, in which case the standby shall expire." The beneficiary interprets this as a PAYM demand, but the standby actually requires a PAEX demand to trigger the extension-or-pay election.

Systemic impact: A PAYM demand under a standby that requires PAEX creates a discrepancy that cannot be corrected after the fact. The issuing bank's examination period begins on the business day following presentation (ISP98 Rule 5.01(a)(iii)). If the bank dishes the demand within three to seven business days, the beneficiary's re-presentation window may have expired. The demand itself has mutated from a valid claim into a terminal discrepancy.

Failure Mode 2: INCP Demand Without Field 77

The beneficiary submits an MT 765 with Field 49A coded as INCP (Incomplete demand) but omits Field 77 (Presentation Completion Details). SWIFT's Network Validated Rule C1 blocks the message at the network level: "If the code in field 49A is INCP, field 77 must be present." The MT 765 never reaches the issuing bank.

Root cause: The beneficiary's SWIFT operator selects INCP when the demand will be followed by supporting documentation — a certificate of default, a court order, or a statement of the drawing event — but fails to populate Field 77 with the details of when and how the supporting documentation will be presented. The operator treats Field 77 as optional because it is marked "O" (Optional) in the format specification, missing the conditional mandatory rule triggered by INCP.

Systemic impact: The demand is not merely discrepant — it is non-existent. The issuing bank never receives it. The beneficiary believes the demand has been presented, the standby's expiry window continues to close, and the beneficiary discovers the failure only when the bank confirms non-receipt. Under ISP98 Rule 5.04, "Failure to give notice that a presentation was made after the expiration date does not preclude dishonour for that reason." The late discovery compounds the initial failure.

Failure Mode 3: Amount Exceeding Available Balance

The beneficiary submits an MT 765 with Field 32B (Demand Amount) that exceeds the available balance under the standby. ISP98 Rule 3.08(e) provides: "If a demand exceeds the amount available under the standby, the drawing is discrepant. Any document other than the demand stating an amount in excess of the amount demanded is not discrepant for that reason." The excess amount does not truncate to the available balance — the entire demand is discrepant.

Root cause: The standby may have been partially drawn, may have been reduced by prior demands, or may include a reduction clause triggered by a specified event (e.g., shipment of goods). The beneficiary calculates the available balance based on the standby's face value without accounting for prior draws or reduction triggers. The SWIFT operator enters the full face value in Field 32B.

Systemic impact: The discrepant amount triggers a dishonour notice under ISP98 Rule 5.02. The beneficiary must then re-submit a corrected demand — but the standby may have expired in the interim. Unlike a documentary credit where a corrected presentation can be made within the five-banking-day examination window, a standby demand that is dishonoured for amount excess creates a race against the expiry date. The beneficiary's failure to compile the correct amount in the initial demand decouples the claim from the available balance and may result in total loss of the payment right.

Deterministic Resolution Architecture

1. Demand type pre-verification. Before constructing the MT 765, the beneficiary must cross-reference Field 21M against the standby's demand provisions. If the standby contains an automatic extension clause, the demand must be coded PAEX. If the standby is a straight payment obligation, the demand must be coded PAYM. This is a binary determination — there is no intermediate code. The verification should be documented in writing and attached to the demand file.

2. INCP/Field 77 coupling check. When Field 49A is coded INCP, the SWIFT operator must populate Field 77 with: (a) the type of supporting documentation to follow, (b) the medium of presentation (physical documents, SWIFT message, electronic submission), and (c) the expected timeline for completion. SWIFT's Network Validated Rule C1 enforces this coupling at the network level — an INCP demand without Field 77 will be rejected before it reaches the issuing bank. The operator should run a pre-transmission validation against the C1 rule.

3. Amount reconciliation protocol. The beneficiary must compile the current available balance by: (a) confirming the standby's original face value, (b) subtracting all prior honoured draws, (c) applying any reduction triggers specified in the standby, and (d) verifying that no pending amendments have modified the amount. The resulting figure is the maximum permissible Field 32B amount. If the standby permits partial draws, the beneficiary may submit for less than the full available balance — but never more.

4. Expiry date monitoring. The beneficiary must maintain a live expiry tracker for every standby. ISP98 Rule 3.02(a) provides that "a presentation must be made not later than the date on which the standby expires." For standbys with automatic extension clauses, the beneficiary must track the extension trigger date (typically 30 days before the current expiry) and submit the PAEX demand within the required notice period. The tracker must account for business day adjustments under Rule 3.01 — if the expiry falls on a non-business day, presentation is due on the first following business day.

5. Post-presentation monitoring. After transmitting the MT 765, the beneficiary must monitor the issuing bank's response within the ISP98 Rule 5.01 window. Notice of dishonour given within three business days is deemed not unreasonable; beyond seven business days is deemed unreasonable. If no notice is received within seven business days, the beneficiary should issue a follow-up inquiry. Under Rule 5.03(b), "Failure to give notice of dishonour or acceptance or acknowledgement that a deferred payment undertaking has been incurred obligates the issuer to pay at maturity."

6. Dishonour response protocol. If the issuing bank dishes the demand, the beneficiary must: (a) obtain the complete discrepancy notice under Rule 5.02, (b) assess whether each discrepancy is valid under the standby's terms and ISP98, (c) determine whether the standby remains within its expiry window for re-presentation, and (d) either correct the discrepancies and re-submit or escalate to arbitration under the standby's dispute resolution clause. The beneficiary must not assume that a dishonoured demand extinguishes the underlying obligation — it does not. The standby remains in force until its expiry date, and the beneficiary retains the right to present a complying demand at any time before expiry.

Conclusion

The MT 765 is not a message — it is an executed legal instrument. Every field carries a binary compliance obligation. The demand type code determines the payment mechanism. The narrative text constitutes the demand itself. The amount must reconcile to the available balance. The INCP/Field 77 coupling must be validated at the network level. A failure in any of these fields does not produce a minor discrepancy — it produces a terminal dishonour that may extinguish the beneficiary's payment right if the standby expires before correction.

The systemic lesson is that MT 765 construction requires the same precision as the underlying standby's drafting. The beneficiary cannot treat the demand as a clerical step. It is the point where the standby's abstract obligation becomes a concrete payment claim — and every field in the message is either compliant or discrepant. There is no middle ground.

FAQ

Q1: Can a beneficiary submit an MT 765 with Field 21M coded as PAYM when the standby contains an automatic extension clause?

A: No. ISP98 Rule 3.09 provides that a request to extend the expiry date — or alternatively to pay — "is a presentation demanding payment under the standby, to be examined as such in accordance with these Rules." The standby's automatic extension clause creates an obligation that the beneficiary must either trigger (via PAEX) or decline (via PAYM). A PAYM demand under a standby that requires PAEX does not comply with the standby's terms and is dishonourable under ISP98 Rule 5.02.

Q2: What happens if the issuing bank fails to give notice of dishonour within seven business days?

A: Under ISP98 Rule 5.01(a)(ii), notice given beyond seven business days is "deemed to be unreasonable." Under Rule 5.03(b), "Failure to give notice of dishonour or acceptance or acknowledgement that a deferred payment undertaking has been incurred obligates the issuer to pay at maturity." The beneficiary should document the timeline and, if the standby provides for deferred payment, treat the issuer's silence as an acknowledgement of the deferred payment undertaking.

Q3: Is the MT 765 demand amount required to match the standby's face value exactly?

A: No — but it must not exceed the available balance. ISP98 Rule 3.08(e) provides: "If a demand exceeds the amount available under the standby, the drawing is discrepant." If the standby permits partial draws, the beneficiary may submit for less than the full available balance. If the standby requires a full draw ("drawn in full"), the demand must be for the entire available amount. Rule 3.08(f) permits a tolerance of 10 per cent more or less when words like "approximately," "about," or "circa" are used.

Q4: Can the demand statement in Field 49A be combined with a required certificate or declaration?

A: Only if the standby expressly permits it. ISP98 Rule 4.15(a) states: "A demand for payment need not be separate from the beneficiary's statement or other required document." However, Rule 4.15(b) requires that if a separate demand is required, it must contain a demand for payment, a date, an amount, and the beneficiary's signature. The beneficiary must verify the standby's specific demand provisions before deciding whether to combine or separate the demand from other documents.

Q5: What is the consequence of submitting an MT 765 with Field 32B amount that exceeds the standby balance due to a prior unreleased draw?

A: The entire demand is discrepant under ISP98 Rule 3.08(e). The excess amount does not truncate to the available balance — the demand is dishonoured in its entirety. The beneficiary must then re-submit a corrected demand, but the standby may have expired in the interim. Under Rule 3.02(a), a presentation must be made not later than the standby's expiry date. The beneficiary's failure to account for prior draws in the initial MT 765 may result in total loss of the payment right if the expiry window closes before correction.