MT700 Field 50 — Common Errors and Discrepancies

Introduction

SWIFT MT700 Field 50 identifies the applicant — the party on whose request the issuing bank issues the documentary credit. Practitioners treat this field as a straightforward identification block, but that illusion collapses under scrutiny. Field 50 errors do not merely create cosmetic mismatches; they trigger cascading documentary failures that propagate across invoice presentation, transport document notation, certificate of origin naming, and beneficiary identification. This guide isolates the three most destructive error patterns in Field 50, traces each to its UCP 600 and ISBP 745 root, and provides a deterministic resolution architecture.

Failure Mode Analysis

Failure Mode 1: Applicant Name Truncation in SWIFT Character Limits

The SWIFT MT700 format imposes strict character limits on Field 50. In the free-format options (Field 50A or Field 50K), the applicant name is typically constrained to 4 x 35 characters. When the applicant's full legal name exceeds this limit, the issuing bank truncates. This creates a deterministic failure path:

1. The issuing bank enters Field 50 with the first 35 characters of a 48-character entity name.
2. The beneficiary prepares a commercial invoice "made out in the name of the applicant" using the full legal name (per the underlying sale contract).
3. The examining bank compares Field 50 data against the invoice and detects a name discrepancy.
4. A discrepancy is raised under Article 14(d) — conflict with data in the credit.

The systemic trap: The beneficiary cannot comply with both the truncated SWIFT data and the full legal name requirement from the sale contract. The error originates at the issuing bank's data entry, but the financial consequence falls on the beneficiary through refused documents and discrepancy fees.

ISBP 745 paragraph A1 permits "widely recognized abbreviations," but truncation is not abbreviation — it is data loss. The truncated string "INTERNATIONAL TRADING COMPA" is not an abbreviation of "INTERNATIONAL TRADING COMPANY LIMITED"; it is a partial, non-functional identifier. ISBP 745 A1 provides no safe harbor here.

Failure Mode 2: Country Code Mismatch Between Field 50 and Document Addresses

Field 50 in the structured format options (Field 50F) requires an explicit country code. Errors manifest in two variants:

Variant A — Wrong country code entered: The issuing bank selects "DE" (Germany) when the applicant is registered in "AT" (Austria). This is a data entry mutation that propagates to every document referencing the applicant's address.

Variant B — Country code absent in free-format entries: In Field 50A or 50K, practitioners frequently omit the country from the address block, relying on the city name to imply jurisdiction. UCP 600 Article 14(j) requires the address to be "within the same country as the respective addresses mentioned in the credit." When the country is absent from Field 50, there is no reference point for the country comparison, and the examining bank has no basis to confirm or deny compliance.

The binary outcome: Under Article 14(j), a country mismatch is a violation — not a discrepancy subject to waiver negotiation, but a structural breach. The applicant's address on the invoice must reside in the same country stated in the credit. If Field 50 says Germany and the invoice says Austria, the presentation is non-complying. Full stop. The issuing bank cannot waive this under Article 16(b) without fundamentally misapplying the rules.

Failure Mode 3: Field 50 and Field 59 Identity Overlap

Field 50 (Applicant) and Field 59 (Beneficiary) describe two distinct parties. When these fields contain overlapping or identical information — a common occurrence in related-party transactions, back-to-back credits, or mirror arrangements — the examining bank encounters a logical contradiction. The credit identifies the same entity as both the party requesting issuance and the party in whose favor the credit is issued.

UCP 600 Article 4(a) establishes the separateness principle:

"A credit by its nature is a separate transaction from the sale or other contract on which it may be based."

When Field 50 and Field 59 describe the same entity, the credit's internal logic collapses. The beneficiary is simultaneously the buyer and the seller. While Article 4 does not explicitly prohibit this scenario, ISBP 745 preliminary consideration (iv) states:

"Many of the problems that arise at the document examination stage could be avoided or resolved by the respective parties through careful attention to detail in the credit or amendment application and issuance of the credit or any amendment thereto."

The examining bank must determine whether documents "made out in the name of the applicant" (Article 18(a)(ii)) and documents "issued by the beneficiary" (Article 18(a)(i)) are referencing the same entity. When they are, the commercial invoice requirement of Article 18(a)(i) and (a)(ii) merge — the invoice must be issued by and made out in the name of the same party. This creates a compliance pathway, but only if the beneficiary's name on the invoice is identical to the applicant name in Field 50. Any variance — even an abbreviation — violates both sub-articles simultaneously.

Deterministic Resolution Architecture

Resolution 1: Pre-Issuance Validation of Field 50 Character Length

Before the issuing bank transmits the MT700, it must verify that the full legal name of the applicant fits within the SWIFT field constraints. If it does not:

1. Use Field 50F (structured format) with explicit tag coding, which accommodates longer names across multiple sub-lines.
2. If the name still exceeds limits, add a field 79 (Narrative) or field 47A (Additional Conditions) clause stating: "Applicant name as shown in this credit is a shortened form of the full legal name [FULL LEGAL NAME]. Documents showing either the shortened or full form are acceptable."
3. Alternatively, instruct the beneficiary via a pre-advice (Article 11(b)) that the applicant's full legal name will differ from Field 50.

Resolution 2: Country Code Verification Protocol

Implement a mandatory cross-check at the issuing bank:

1. Extract the country code from Field 50F, or parse the city/country from Field 50A/50K address lines.
2. Compare against the applicant's registered jurisdiction (from the LC application form).
3. Verify the country on all stipulated documents that reference the applicant's address (certificate of origin, insurance document, transport document notify party).
4. If any mismatch is detected, refuse to issue until corrected — the cost of pre-issuance correction is zero; the cost of post-presentation discrepancy is the entire transaction value.

Resolution 3: Related-Party Transaction Disclosure

When Field 50 and Field 59 describe the same or related entities:

1. The issuing bank must add a narrative condition (Field 47A or 79) explicitly acknowledging the related-party structure.
2. The condition should state: "Applicant and Beneficiary are related parties. The commercial invoice is to be issued by and made out in the name of the Beneficiary as stated in Field 59."
3. The beneficiary must ensure that the invoice name matches Field 59 exactly, and that the "made out in the name of the applicant" requirement of Article 18(a)(ii) is satisfied by the identical naming.

Resolution 4: Discrepancy Rebuttal Framework

When a Field 50 discrepancy is raised and the presenter believes it is unsound:

1. Cite UCP 600 Article 14(d): data must not conflict when read in context with the credit and international standard banking practice.
2. Demonstrate that the Field 50 data and the document data do not conflict — they describe the same entity using different but non-contradictory identifiers.
3. Cite ISBP 745 paragraph A1 for abbreviation tolerance, but only if the difference is genuinely an abbreviation (not truncation).
4. If the discrepancy involves country codes, concede — Article 14(j) violations are binary and non-rebuttable.

Conclusion

Field 50 errors are not isolated data-entry problems. Each error mutates the entire documentary compliance chain. The issuing bank's obligation to ensure accuracy in Field 50 is not merely administrative — it is a systemic requirement that determines whether the beneficiary can achieve a complying presentation. Banks that treat Field 50 as a low-priority transcription task will generate discrepancy notices that are technically defensible but practically indefensible, creating friction that erodes the letter of credit's utility as a payment mechanism.

The deterministic path forward: validate Field 50 against the LC application before transmission, cross-reference it against all stipulated document requirements, and disclose any naming limitations through explicit narrative conditions. The marginal cost of these checks at issuance is negligible; the cost of failing to perform them is measured in refused documents, discrepancy fees, and lost trust.

FAQ

Q1: If the applicant's name in Field 50 is truncated due to SWIFT character limits, and the commercial invoice shows the full legal name, is this a valid discrepancy?

It depends on the examining bank's interpretation of Article 14(d). If the truncated name is a partial but recognizable subset of the full legal name (e.g., "INTERNATIONAL TRADING CO" vs. "INTERNATIONAL TRADING COMPANY LIMITED"), many banks will accept the presentation because the data does not conflict — it is incomplete but not contradictory. However, if the truncation produces an unrecognizable string, or if the truncated form could refer to a different entity, the discrepancy is valid. The safest path is for the issuing bank to include a narrative condition in Field 47A or 79 explicitly linking the truncated Field 50 name to the full legal entity.

Q2: Under UCP 600 Article 14(j), does the applicant's address on the commercial invoice need to match the address in Field 50 exactly?

No. Article 14(j) states that addresses "need not be the same as those stated in the credit or in any other stipulated document, but must be within the same country." The country is the only immutable element. A difference in street address, postal code, or city between Field 50 and the invoice is not a discrepancy. A difference in country is a violation — and one that cannot be waived by the applicant under Article 16(b), because it is not a discrepancy the applicant can authorize the bank to accept; it is a structural failure of the presentation.

Q3: ISBP 745 allows "widely recognized abbreviations" (paragraph A1). Can I abbreviate the applicant name on documents to match a shortened Field 50?

ISBP 745 A1 covers abbreviations like "Co." for "Company," "Ltd" for "Limited," and "Ind." for "Industry." These are word-level substitutions that preserve the entity's identity. Truncation is not abbreviation — cutting "INTERNATIONAL TRADING COMPANY LIMITED" to "INTERNATIONAL TRADING COMPA" is data loss, not a recognized abbreviation. If the Field 50 name is a genuine abbreviation (e.g., "Intl Trading Co Ltd"), the beneficiary may use the same abbreviation or the full form on documents. If it is a truncation, the beneficiary should present documents using the full legal name and request that the issuing bank reconcile the discrepancy against its own data entry error.

Q4: Can the issuing bank waive a Field 50 country code mismatch under Article 16(b)?

Article 16(b) allows the issuing bank to approach the applicant for a waiver when a presentation does not comply. However, a country code mismatch under Article 14(j) is a conflict between the credit and the document — not a discrepancy the applicant can waive, because the applicant's own address data is the source of the conflict. The applicant cannot simultaneously assert that its country is Germany (in Field 50) and Austria (on the invoice) and authorize the bank to accept both. The resolution requires either an amendment to correct the credit, or the beneficiary correcting the invoice — not a waiver.

Q5: What happens if Field 50 and Field 59 contain identical information in a back-to-back credit structure?

The credit is internally consistent if the applicant and beneficiary are the same entity, provided the commercial invoice is issued by and made out in the name of that entity (satisfying both Article 18(a)(i) and (a)(ii)). The examining bank should not raise a discrepancy solely because Field 50 and Field 59 overlap. However, the issuing bank should include a narrative condition acknowledging the related-party structure to prevent downstream confusion. If the names are not identical but merely similar (e.g., parent company in Field 50, subsidiary in Field 59), each document must correctly reference the entity that issued or is the subject of that specific document — the invoice must be made out in the name of the entity stated in the credit as the applicant, which is Field 50, not Field 59.