MT700 Field 72 — Common Errors and Discrepancies in Sender-to-Receiver Information

Introduction

Field 72 of the SWIFT MT700 message — Sender to Receiver Information — is the free-format narrative field that transmits supplementary instructions between banks issuing and advising documentary credits. Practitioners treat it as a residual catch-all: anything that does not fit neatly into the structured fields (46A, 47A, 78, 49) gets pushed into Field 72. This creates a systemic failure mode. Field 72 carries the same legal weight as any other field in the MT700, yet its unstructured format invites errors that mutate simple instructions into unrecoverable discrepancies. When Field 72 contradicts another field, omits required SWIFT codes, or contains improperly formatted structured text, the receiving bank cannot compile a compliant document examination, and the documentary credit transaction fractures into dispute.

Failure Mode Analysis

Failure Mode 1: Field 72 Contradicts Structured Fields (Field 47A / Field 78)

This is the most frequent source of disputes. The issuing bank populates Field 47A with additional conditions — for example, "Documents must be issued in triplicate" — but Field 72 contains a supplementary instruction stating "One copy of each document sufficient." The receiving bank must determine which instruction controls. Under Article 14(d), both fields are "data in the credit." There is no hierarchical rule in UCP 600 that gives Field 47A precedence over Field 72. The result is ambiguity that the receiving bank cannot resolve deterministically.

Root cause: The issuing bank drafts Field 72 as an afterthought, adding instructions that were already addressed — or contradicted — in the structured fields. The two drafting events are decoupled; no single reviewer compiles the full message before transmission.

Failure Mode 2: Missing or Improperly Formatted SWIFT Codes

SWIFT requires that codes like /PHONBEN/ and /TELEBEN/ appear at the beginning of a line, enclosed in slashes. Common errors include:

• Placing the code after narrative text on the same line
• Omitting the trailing slash
• Using non-standard codes not in the SWIFT catalogue
• Inserting codes without the required slash delimiters

These formatting violations mutate the code from an operational instruction into unstructured noise. The receiving bank's parser may interpret the malformed code as narrative text, causing the intended instruction to be isolated from its operational context.

Root cause: Staff unfamiliar with SWIFT's structured text rules enter Field 72 content as free text, assuming the system will auto-format. The system does not.

Failure Mode 3: Field 72 Contains Conditions Requiring Document Presentation

This failure mode violates Article 14(h) by design. When Field 72 states "Beneficiary must provide evidence of origin" without requiring a specific document in Field 46A to evidence that condition, the condition is a non-documentary condition under Article 14(h). Banks will disregard it. But the issuing bank intended it to be binding. The beneficiary, unaware that the condition will be disregarded, either complies (wasting effort) or does not comply (risking an unrelated discrepancy claim).

Root cause: The issuing bank uses Field 72 as a secondary field for conditions that should have been placed in Field 47A with a corresponding document requirement in Field 46A.

Deterministic Resolution Architecture

1. Implement a pre-transmission compilation check. Before the MT700 is sent, a single reviewer must read the entire message — all fields, including Field 72 — and verify that no field contradicts another. This check must be documented and logged.

2. Establish a Field 72 content policy. Restrict Field 72 to information that is genuinely supplementary: contact instructions (/PHONBEN/, /TELEBEN/), references to pre-issuance agreements, and clarifications that do not create new conditions. Any new condition must go to Field 47A with a corresponding document requirement in Field 46A.

3. Decouple the SWIFT code entry from the narrative entry. Require that structured codes be entered in a separate data field from the narrative text, with system-level validation that enforces slash delimiters and line-start positioning. This isolates the code from the narrative and prevents formatting mutation.

4. Audit Field 72 against Article 14(h). Every condition in Field 72 must be checked: does it require a document? If yes, the document must appear in Field 46A. If no, the condition will be disregarded under Article 14(h) — confirm this is the issuing bank's intent before transmission.

5. Flag temporal terms for Article 3 review. Any Field 72 content containing "prompt," "immediately," or "as soon as possible" must be flagged and either reworded to a specific time period or removed, since Article 3 will cause the receiving bank to disregard these terms.

6. Maintain a Field 72 error log. Every discrepancy triggered by Field 72 content must be logged, categorized, and reviewed quarterly. This log compiles the data needed to identify systemic patterns and adjust the Field 72 content policy.

7. Implement automated SWIFT validation. Deploy validation rules that check Field 72 format compliance (6*35z, code delimiters, line positioning) before the message enters the SWIFT network. Reject non-compliant messages at the originator's system.

Conclusion

Field 72 is not a free pass. It is a structured SWIFT field with formatting rules, and its content carries the same legal weight as any other field in the MT700. The three failure modes — contradictions with structured fields, improper code formatting, and non-documentary conditions — all stem from the same root: treating Field 72 as a catch-all rather than as a field with specific constraints. The resolution architecture compiles deterministic checks at each stage: pre-transmission review, content policy enforcement, system-level format validation, and post-transaction error logging. Banks that implement these controls will find that their Field 72 discrepancies decline to zero — not because the field is simple, but because the errors are preventable.

FAQ

Q1: What happens when Field 72 contradicts Field 47A?
Under UCP 600 Article 14(d), both fields contain "data in the credit." There is no built-in rule giving one field precedence over the other. The receiving bank must apply Article 14(d)'s prohibition on conflicting data and determine whether the contradiction renders the presentation discrepant. In practice, the bank will contact the issuing bank for clarification, but this delays payment and creates risk. The only reliable prevention is the pre-transmission compilation check described in the Resolution Architecture.

Q2: Can Field 72 contain conditions that the beneficiary must comply with?
Yes, but with a binary caveat. Under Article 14(h), any condition in the credit — including Field 72 — that does not stipulate a document to indicate compliance will be disregarded by banks. If the issuing bank intends a condition to be binding, it must specify both the condition in Field 47A and the document evidencing compliance in Field 46A. A condition in Field 72 alone will be treated as non-documentary and disregarded.

Q3: What are the valid SWIFT codes for Field 72 in an MT700?
The SWIFT standards for the MT700 (November 2018-2019) recognize two codes for Field 72Z: /PHONBEN/ (Telephone beneficiary) and /TELEBEN/ (Telecommunication — advise beneficiary by the most efficient means). These codes must appear at the beginning of a line, enclosed in slashes. Any other codes are not standard for Field 72 in an MT700 and may cause validation errors.

Q4: Does Field 72 survive a subsequent mail confirmation?
Yes. Under UCP 600 Article 11(a), an authenticated teletransmission of a credit is deemed to be the operative credit. Field 72 content in the MT700 teletransmission is part of the operative credit and cannot be overwritten by a later paper confirmation. The mail confirmation is disregarded.

Q5: What SWIFT validation errors can Field 72 trigger?
The most common are C01 (Missing Mandatory Field), C04 (Wrong Format), and narrative length violations when content exceeds 35 characters per line. Non-standard codes (anything other than /PHONBEN/ or /TELEBEN/) may also trigger format validation errors. The automated validation rules in the Resolution Architecture check for these before the message enters the SWIFT network.