MT700 Field 50 and Its Relationship with UCP 600

Introduction

Field 50 of the SWIFT MT700 message identifies the applicant — the party on whose request the issuing bank issues the documentary credit. This identification field appears straightforward, but it creates documentary obligations that ripple across the entire UCP 600 compliance architecture. The applicant's identity in field 50 determines which documents reference that party, which documents the applicant must issue or authorize, and which naming conventions the beneficiary must follow when preparing the presentation.

This guide examines field 50's role in the documentary credit lifecycle under UCP 600, identifies the compliance failure modes that originate in field 50 data, and establishes a deterministic method for aligning field 50 with every applicant-dependent document in the set.

Failure Mode Analysis

Failure Mode 1: Legal Name Variation Between Field 50 and Documents

Applicants register under specific legal names that include entity suffixes — Ltd., Inc., GmbH, S.A., LLC. Field 50 records the full legal name. When the beneficiary abbreviates or modifies this name on documents, the examining bank flags the difference. "Smith & Jones Ltd." versus "Smith & Jones Limited" produces a discrepancy even though both names refer to the same entity.

Failure Mode 2: Incomplete Address Data in Field 50

Field 50 sometimes contains only the applicant's name without a complete address. When the credit requires documents — such as insurance certificates or certificates of origin — that must show the applicant's address, the beneficiary cannot produce a compliant document because the authoritative address data is missing from the SWIFT message.

Failure Mode 3: Multiple Entities Listed in Field 50

Some MT700 messages list multiple entities in field 50 — for example, "ABC Trading Co. c/o XYZ Shipping Ltd." or "ABC Trading Co. / ABC Finance GmbH." The examining bank must determine which entity is the applicant for documentary purposes. If the invoice references only one entity, but field 50 lists two, the bank may flag the mismatch.

Failure Mode 4: Field 50 References a Parent Company, Documents Reference a Subsidiary

In corporate structures, the applicant may be a parent company while the actual buyer is a subsidiary. Field 50 identifies the parent, but documents reference the subsidiary. The examining bank compares the documents against field 50, not against the commercial reality of the transaction.

Failure Mode 5: Field 50 Data Differs From the Credit Text's Applicant Clause

The MT700 message may contain an applicant clause in field 78 or the credit text that uses a different name or address than field 50. This dual-reference creates confusion about which entity is the authoritative applicant.

Deterministic Resolution Architecture

Step 1: Extract and Record Field 50 Data Completely

Parse the SWIFT MT700 message and extract field 50 data line by line. Record every character — name, address, city, country — without modification. This extraction becomes the canonical applicant reference for the entire document set.

Step 2: Identify Every Document Requiring Applicant Reference

Create a list of all documents required by the credit and determine which ones reference the applicant. Common applicant-referenced documents include: commercial invoice, bill of lading (consignee), certificate of origin, insurance certificate, inspection certificate, and packing list.

Step 3: Use Exact Field 50 Name on All Applicant-Referenced Documents

Apply the exact name from field 50 on every document that references the applicant. Do not abbreviate, expand, or add qualifiers. If field 50 states "Pacific Rim Trading Company Limited," that exact string must appear on the invoice, the bill of lading consignee, and any certificate referencing the applicant.

Step 4: Verify Address Data Against Field 50

For documents requiring the applicant's address, use the address from field 50. If field 50 provides no address, contact the advising bank to request an amendment or clarification before preparing documents. Do not substitute an address from external knowledge.

Step 5: Resolve Multi-Entity Field 50 Structures

When field 50 lists multiple entities, determine the primary applicant by examining the credit text and the transaction structure. Use the primary entity on all applicant-referenced documents. If ambiguity persists, request clarification from the issuing bank through the advising bank.

Step 6: Validate Consignee Against Field 50 on Transport Documents

For bills of lading and other transport documents requiring consignee data, verify that the consignee matches the field 50 applicant. If the credit requires the transport document consigned to the applicant, the consignee field must show the field 50 entity. If the credit requires "to order of issuing bank," the consignee follows the credit's instructions regardless of field 50.

Step 7: Reconcile Field 50 Against Field 46A (Document Requirements)

Cross-reference field 50 against field 46A to identify every document clause that references the applicant. For each clause, verify that the document's applicant data matches field 50. This cross-reference identifies discrepancies before submission.

Step 8: Perform Final Field 50 Consistency Audit

Before presenting documents, verify: (a) the commercial invoice names the field 50 applicant, (b) the bill of lading consignee matches field 50 where required, (c) all certificates referencing the applicant use the field 50 name and address, and (d) no document references an entity that differs from field 50. Record the audit results.

Conclusion

Field 50 is the applicant's identity anchor in the SWIFT MT700 message. Its data determines the naming conventions for the entire document set. The UCP 600 examination regime — Articles 14(a), 14(f), and 37(b) — evaluates documents against field 50 as the authoritative applicant reference. Discrepancies arise when documents deviate from field 50 data in name, address, or entity designation.

The resolution architecture requires the beneficiary to treat field 50 as the single source of truth for applicant identity and to apply that data consistently across every applicant-referenced document. This approach eliminates the naming, addressing, and entity mismatches that produce most field 50-related rejections.

FAQ

Q1: What if field 50 contains only a name and no address?
The beneficiary should request amendment or clarification through the advising bank. Documents requiring the applicant's address cannot be completed accurately without authoritative address data. If the credit text contains an address clause, use that data; otherwise, the incomplete field 50 creates a documentary gap.

Q2: Can the beneficiary abbreviate the applicant name from field 50?
No. The examining bank performs a literal comparison between the applicant name on documents and the name in field 50. Any abbreviation, expansion, or modification produces a discrepancy under Article 37(b) for the invoice or Article 14(a) for other documents.

Q3: How does field 50 interact with field 52 (ordering institution)?
Field 52 identifies the bank that ordered the issuance of the credit — typically the advising bank or another intermediary bank. Field 50 identifies the applicant. These are distinct parties. Documents must reference the applicant (field 50), not the ordering bank (field 52), when the credit requires applicant references.

Q4: What happens if field 50 and the credit text name different applicants?
The SWIFT message governs. Field 50 is the SWIFT carrier of the applicant's identity and is the reference point for document examination. When a conflict exists, the beneficiary should seek clarification from the issuing bank before preparing documents.

Q5: Does the examining bank contact the applicant to verify field 50 data?
No. The examining bank evaluates documents on their face against the SWIFT message data. It does not contact the applicant to verify the accuracy of field 50 or to resolve ambiguities in the applicant's identity.

Q6: Can field 50 contain a P.O. Box as the applicant's address?
A P.O. Box is acceptable if it is the registered address of the applicant entity. However, some credits prohibit P.O. Box addresses on certificates of origin or other government-issued documents. The beneficiary must verify the credit's specific requirements for address format.

Source Notes

Context only: The source dossier for this guide referenced ICC Academy publications on MT700 field structures and documentary credit compliance. No text from those sources has been reproduced. This guide was composed from first principles using the UCP 600 text, ISBP 745, SWIFT MT700 specifications, and the author's independent analysis of field 50's role in documentary credit compliance.