MT700 Field 59 — Common Errors and Discrepancies

Introduction

Field 59 (Beneficiary) in a SWIFT MT700 issuance message carries the name and address of the party in whose favour the letter of credit is opened. It is not a peripheral data element — it is the identity anchor that every downstream document must reference. An error in Field 59 does not stay contained. It propagates into the commercial invoice, the draft, certificates of origin, insurance documents, and every transport document that names the beneficiary or consignor. The result is a chain of discrepancies that can collapse an otherwise compliant presentation into a refusal under UCP 600 sub-article 16 (c) (ii).

The systemic failure mode is this: the issuing bank inputs Field 59 data that deviates from the beneficiary's actual legal entity name, registered address, or both. The beneficiary then presents documents that are, in substance, correct — but that fail a literal string-match against the MT700. The examining bank applies UCP 600 sub-article 14 (d) and declares a mismatch. The beneficiary faces a discrepancy notice, a discrepancy fee, and a potential loss of the credit's expiry window.

This guide isolates the three dominant failure modes in Field 59 and provides a deterministic resolution architecture for each.

Failure Mode Analysis

Failure Mode 1: Legal Entity Name Mismatch

The issuing bank abbreviates or truncates the beneficiary's legal name in Field 59 to fit the 35-character SWIFT line limit. "Al-Rahman International Trading & Contracting Est." becomes "Al-Rahman International Trading" or "AL RAHMAN INTL TRADING EST." The beneficiary presents documents showing the full registered name. The examining bank refuses the presentation.

Root cause: The SWIFT 4×35 structure imposes a hard character ceiling. The issuing bank's operator manually enters the name, applying ad-hoc abbreviations without consulting the beneficiary's official documentation. The beneficiary has no input into Field 59 content.

Discrepancy classification: This typically generates a discrepancy notice citing "beneficiary name does not correspond with the credit" under sub-article 14 (d). The bank treats the name as data that must not conflict. Whether an abbreviation constitutes a conflict depends on the examining bank's interpretation — a binary determination with no appeals mechanism at the document examination stage.

Failure Mode 2: Address Line Truncation or Omission

The beneficiary's registered address exceeds 105 characters (3 lines × 35 characters). The issuing bank truncates the address, omits postal codes, or drops secondary address lines. The beneficiary's invoice shows the complete address. The examining bank notes the discrepancy between the credit's address (truncated) and the invoice's address (complete).

Root cause: SWIFT's fixed-width field structure cannot accommodate addresses in many jurisdictions — particularly those with lengthy administrative subdivisions (e.g., Chinese addresses with province, city, district, and street designations). The issuing bank operator, under time pressure, compresses or omits address components.

Discrepancy classification: Under UCP 600 sub-article 14 (j), address variations within the same country are tolerable. However, if the truncation removes the country name entirely, the "same country" test becomes impossible to apply. The examining bank may also treat the address omission as a conflict under sub-article 14 (d) if it considers the address a material element of the beneficiary's identity.

Failure Mode 3: Beneficiary/Applicant Name Confusion in Transferable Credits

In a transferable credit, the transferring bank substitutes the first beneficiary's name for the applicant's name in certain fields. UCP 600 sub-article 38 (g) permits this substitution. However, the transferring bank fails to update Field 59 to reflect the second beneficiary's identity, or updates it incorrectly — for example, inserting the first beneficiary's name where the second beneficiary's name should appear. The second beneficiary presents documents under its own name, which does not match Field 59.

Root cause: The transfer process involves manual re-keying of MT700 fields. The transferring bank's operator must substitute names across multiple fields (59, 50A, 45A, 46A, 47A) while preserving the credit's commercial logic. Errors in this multi-field substitution are common and often cascade.

Discrepancy classification: The second beneficiary's documents will show its own name, which does not match Field 59. Unless the second beneficiary invokes ISBP 745 paragraphs B8 (b) or C2 (b) — "formerly known as" — the presentation is discrepant. The "formerly known as" mechanism is the only deterministic path to compliance in this scenario.

Deterministic Resolution Architecture

1. Pre-issuance validation. The applicant should verify Field 59 against the beneficiary's commercial registration or trade license before the issuing bank transmits the MT700. This is the cheapest interception point. A two-minute cross-check eliminates the most common failure modes.

2. Abbreviation standardization. When the beneficiary's name exceeds 35 characters, the issuing bank should apply the abbreviations sanctioned by ISBP 745 paragraph A1 — "Co." for "Company," "Ltd" for "Limited," "Intl" for "International" — rather than inventing ad-hoc truncations. The applicant should instruct the issuing bank to use these standard abbreviations.

3. Address compression protocol. When the address exceeds three lines, the issuing bank should prioritize the country name, city, and postal code. Under sub-article 14 (j), the "same country" test is the decisive threshold. Ensure the country is never truncated. Secondary address details (building numbers, floor references, postal district codes) may be omitted if the country and city are preserved.

4. "Formerly known as" invocation. When the beneficiary has changed its legal name but the credit was issued under the old name, the beneficiary must include "formerly known as [old name]" on the draft (ISBP 745 B8 (b)) and the invoice (ISBP 745 C2 (b)). This is not optional — it is the only sanctioned mechanism for reconciling a name change with an existing credit. Failure to include this phrase renders the presentation discrepant.

5. Transferable credit name chain. The transferring bank must verify that Field 59 in the transferred credit reflects the second beneficiary's name, not the first beneficiary's name. The first beneficiary's name should appear only where sub-article 38 (g) expressly permits substitution (typically Field 50A, the applicant field). The transferring bank should perform a field-by-field audit of the MT701 amendment to the transferred credit before transmission.

6. Discrepancy response under sub-article 16. If a Field 59 discrepancy is raised, the beneficiary should immediately assess whether the variation is addressable under ISBP 745 A1 (abbreviations), A23 (misspellings), or 14 (j) (address tolerance). If the variation falls within any of these tolerances, the beneficiary should prepare a written rebuttal citing the specific ISBP 745 paragraph. The examining bank's five-day examination period (sub-article 14 (b)) does not extend for the beneficiary's rebuttal — the beneficiary must act within the presentation window.

7. Amendment as last resort. If the Field 59 error cannot be reconciled through ISBP 745 tolerances, the beneficiary should request an amendment to correct the name or address. Under sub-article 10 (c), the credit's original terms remain in force until the beneficiary communicates acceptance of the amendment. The beneficiary should reject the discrepant credit and request reissuance with corrected Field 59 data.

Conclusion

Field 59 is the identity anchor of the letter of credit. Every document in the presentation set references the beneficiary's name — on the invoice as issuer, on the draft as drawer, on certificates as the declaring party, on transport documents as shipper or consignor. An error in Field 59 does not produce a single discrepancy; it produces a systemic cascade of discrepancies across the entire presentation.

The resolution architecture is not ambiguous. It is deterministic: verify pre-issuance, apply sanctioned abbreviations, compress addresses while preserving the country, invoke "formerly known as" for name changes, and audit the transfer chain field by field. The UCP 600 and ISBP 745 framework provides sufficient tolerance for minor variations — but only if the issuing bank's input is guided by these rules rather than by ad-hoc operator judgment at the keyboard.

The failure to apply this architecture is not a compliance gap — it is a systemic risk that converts compliant presentations into refused documents and converts banking relationships into dispute resolution proceedings.

FAQ

Q1: If Field 59 states "ABC Trading Co., Ltd." and the invoice shows "ABC Trading Company Limited," is this a discrepancy?

No. ISBP 745 paragraph A1 permits widely accepted abbreviations. "Co." is an abbreviation for "Company" and "Ltd" is an abbreviation for "Limited." A credit that includes an abbreviation allows a document to show the same abbreviation, any other abbreviation with the same meaning, or the complete spelling. The variation between "Co., Ltd." and "Company Limited" is not a conflict under UCP 600 sub-article 14 (d).

Q2: Field 59 truncated the beneficiary's address to two lines. The invoice shows the full four-line address. Is this a discrepancy?

Under UCP 600 sub-article 14 (j), addresses in stipulated documents need not be the same as those stated in the credit, but must be within the same country. If the truncated address in Field 59 still identifies the country, and the invoice's address is in that same country, the variation is tolerable. Contact details (telefax, telephone, email) appended to either address are disregarded for examination purposes. If the truncation removed the country name, the "same country" test cannot be satisfied, and the discrepancy is valid.

Q3: The beneficiary changed its legal name after the credit was issued. Field 59 shows the old name. Can the beneficiary present under the new name?

Yes, but only with the "formerly known as" qualifier. ISBP 745 paragraph B8 (b) allows a draft to be drawn in the name of the new entity provided it indicates "formerly known as (name of the beneficiary or second beneficiary)" or words of similar effect. ISBP 745 paragraph C2 (b) provides the same mechanism for the invoice. Without this phrase, presenting under a name that deviates from Field 59 is a discrepancy.

Q4: In a transferable credit, which name should appear in Field 59 — the first beneficiary's or the second beneficiary's?

Field 59 in the transferred credit should reflect the second beneficiary's name and address. UCP 600 sub-article 38 (g) permits the first beneficiary's name to be substituted for the applicant's name (Field 50A) — not for Field 59. The transferring bank must verify that Field 59 in the MT701 matches the second beneficiary's identity. A mismatch here will generate discrepancies in every document the second beneficiary presents.

Q5: If the examining bank raises a Field 59 discrepancy, does the beneficiary have a right to rebut?

The beneficiary can provide a written explanation citing the applicable ISBP 745 tolerance (A1 for abbreviations, A23 for misspellings, 14 (j) for addresses), but the examining bank's five-day examination period under sub-article 14 (b) does not extend to accommodate the rebuttal. The beneficiary must submit any rebuttal within the presentation window. If the bank maintains its refusal after receiving the rebuttal, the beneficiary's recourse is through the applicant's waiver process under sub-article 16 (b), ICC DOCDEX rules, or the underlying sale contract.