Understanding MT 707: Amendment to a Documentary Credit
Introduction
An MT 707 arrives in a bank's SWIFT queue. The operations team opens it, reads the fields, and assumes the credit is now amended. This assumption — that transmission equals transformation — is the single most dangerous illusion in documentary trade finance. The MT 707 is a message. It is not an amendment. The amendment is a legal event that occurs only when UCP 600 Article 10's consent mechanism is satisfied, the advising bank has authenticated the advice, and the beneficiary has communicated acceptance. Until all three conditions compile into a single operative state, the original credit remains the only enforceable instrument. This guide deconstructs the MT 707 from SWIFT Category 7 message standard through UCP 600 amendment mechanics, isolates the systemic failure modes that produce disputes, and establishes a deterministic resolution architecture that eliminates ambiguity from the amendment lifecycle.
Failure Mode Analysis
Failure Mode 1: Transmission Confused with Amendment
An issuing bank transmits an MT 707. The advising bank receives it. Operations mark the credit as "amended" in the system. The beneficiary has not responded. The presentation is prepared against the amended terms. This is a legal-state error, not a formatting error. Article 10(c) is explicit: the original credit remains in force until the beneficiary communicates acceptance. The SWIFT message is a transport layer event. The amendment is a legal-layer event. Decoupling these two layers produces a presentation examined against terms that do not yet govern the transaction. The bank examining the presentation applies the amended terms; the beneficiary's system retains the original terms. The mismatch generates discrepancies that no party can resolve without reconstructing the consent timeline.
Failure Mode 2: Field Mutation Without Date Recalculation
An MT 707 changes the latest shipment date, the expiry date, or the presentation period. Each date is a separate credit condition. Changing one does not automatically change the others. A new shipment date does not extend expiry. A new expiry does not change the latest shipment date. Operations teams that update only the amended field without recalculating dependent dates produce a credit with internally inconsistent timing controls. The beneficiary ships under the new shipment date but presents after the unamended expiry. The bank examines under Article 14(b) — five banking days from presentation — and determines the presentation is late. The beneficiary's system shows compliance; the bank's system shows a timing violation. The dispute traces back to a failure to isolate each date as an independent variable.
Failure Mode 3: Partial Acceptance Stored as Acceptance
An MT 707 amends three fields: amount, shipment date, and a document requirement. The beneficiary accepts the amount change but rejects the new document requirement. Article 10(e) is unambiguous: "Partial acceptance of an amendment is not allowed and will be deemed to be notification of rejection of the amendment." A system that records "amount accepted" while ignoring the document requirement has stored a partial acceptance — which the rules treat as rejection of the entire amendment. The credit reverts to its pre-amendment state. Any subsequent presentation against the partially-accepted terms is a presentation against a credit version that does not exist. The examining bank applies the original terms; the beneficiary believes the amount amendment is operative. The systemic consequence is a double-state error that propagates through the entire transaction.
Deterministic Resolution Architecture
-
Record the original credit state. Before any amendment is processed, snapshot the operative credit terms: amounts, dates, document requirements, shipment terms, and expiry. This snapshot is the baseline against which all amendments are measured.
-
Capture the MT 707 receipt timestamp. Record when the SWIFT message arrives, when the advising bank authenticates it, and when the beneficiary receives advice. These timestamps establish the amendment's transport-layer history.
-
Decouple the message from the legal event. Store the MT 707 as a received message. Do not mark the credit as amended. The legal event — the amendment becoming operative — occurs only after the consent mechanism in Article 10 is satisfied.
-
Isolate each amended field as an independent variable. Test every amended field against its dependent fields. New shipment date → check expiry. New expiry → check shipment date. New document requirement → check ISBP 745 compliance. Each field mutation triggers a separate validation pass.
-
Record the beneficiary's response as a binary decision. Acceptance or rejection. No partial state. Article 10(e) eliminates the possibility of partial acceptance. The system must enforce this binary constraint at the data model level.
-
Reconstruct the consent chain. Issuing bank issues amendment → confirming bank advises (with or without confirmation) → beneficiary communicates acceptance to the advising bank → advising bank informs the confirming bank → confirming bank informs the issuing bank (Article 10(d)). Each link in this chain must be verified before the amendment is marked operative.
-
Examine against the operative credit version. After the consent chain is complete, update the operative credit record and re-run the examination baseline. Every document, date, amount, and term must be retested against the amended credit.
-
Retain both versions for dispute evidence. The original credit and the amended credit must both be preserved. Disputes frequently arise from the gap between the two versions — who accepted what, when, and under which terms.
Conclusion
The MT 707 is a SWIFT Category 7 message that communicates an amendment proposal. It is not the amendment. The amendment is a legal event governed by UCP 600 Article 10, requiring tripartite consent, authenticated advice, and beneficiary communication. Every failure mode — transmission confused with amendment, field mutation without date recalculation, partial acceptance stored as acceptance — traces to the same root cause: collapsing the message layer and the legal layer into a single state. The resolution architecture isolates these layers, enforces Article 10's binary consent constraint, and ensures that every amendment is tested against the full consent chain before it mutates the operative credit record.
FAQ
Q: Does receiving an MT 707 automatically amend the credit?
A: No. UCP 600 Article 10(a) requires the agreement of the issuing bank, the confirming bank (if any), and the beneficiary. The SWIFT message is the communication mechanism. The amendment becomes effective only when the beneficiary communicates acceptance to the advising bank (Article 10(c)).
Q: Can the beneficiary accept part of an amendment and reject the rest?
A: No. Article 10(e) states: "Partial acceptance of an amendment is not allowed and will be deemed to be notification of rejection of the amendment." The beneficiary must accept all terms or reject the entire amendment. There is no中间状态 (intermediate state).
Q: What happens if the beneficiary does not respond to an amendment?
A: The original credit remains in force (Article 10(c)). However, if the beneficiary makes a presentation that complies with both the original credit and the pending amendment, that presentation constitutes deemed acceptance of the amendment. The amendment becomes operative retroactively to the moment of presentation.
Q: Can an amendment specify that it takes effect unless rejected within a certain time?
A: No. Article 10(f) provides: "A provision in an amendment to the effect that the amendment shall enter into force unless rejected by the beneficiary within a certain time shall be disregarded." Auto-acceptance clauses have no legal effect under UCP 600.
Q: What is the difference between an MT 707 and pre-advice of an amendment?
A: An authenticated MT 707 is the operative amendment under Article 11(a). If the MT 707 states "full details to follow" or similar language, it functions as pre-advice under Article 11(b), and the issuing bank is irrevocably committed to issue the operative amendment without delay in terms not inconsistent with the pre-advice.
UCP 600 Article 10(a) requires the agreement of the issuing bank, the confirming bank (if any), and the beneficiary.
| Regulation | Article / Section | Requirement | Consequence |
|---|---|---|---|
| UCP 600 | Article 10 | Amendments | Binary determination (compliant/discrepant) |
| UCP 600 | Article 1 | Scope of the Rules | Binary determination (compliant/discrepant) |
| UCP 600 | Article 2 | Definitions | Binary determination (compliant/discrepant) |
| UCP 600 | Article 38 | Transferable Credits | Binary determination (compliant/discrepant) |
| UCP 600 | Article 11 | Teletransmission and Pre-Advice | Binary determination (compliant/discrepant) |
| UCP 600 | Article 14 | Standard for Examination of Documents | Binary determination (compliant/discrepant) |
← Scroll horizontally to see all columns
Quick Reference Summary
- No reference captured.
Compliance Checklist
| ✓ What Banks Expect | ✗ What Beneficiaries Often Do Wrong |
|---|---|
| Transmission Confused with Amendment | An issuing bank transmits an MT 707. The advising bank receives it. Operations mark the credit as... |
| Field Mutation Without Date Recalculation | An MT 707 changes the latest shipment date, the expiry date, or the presentation period. Each dat... |
| Partial Acceptance Stored as Acceptance | An MT 707 amends three fields: amount, shipment date, and a document requirement. The beneficiary... |
← Scroll horizontally to see all columns
Get the Full LC Compliance Checklist
15-point pre-submission checklist covering UCP 600, ISBP 745, and SWIFT MT700 fields. Free PDF download.
No spam. Unsubscribe anytime.
DraftLC generates compliant Understanding MT 707 — so you never face this failure mode.
DraftLC drafts your LC with UCP 600-compliant terms and flags conflicts during drafting — before documents reach the bank.
No credit card required · See how DraftLC drafts compliant credits