MT700 Field 31C: Date of Issue — Deterministic Completion Architecture

Introduction

The illusion that Field 31C is merely a date stamp is the first failure mode. In reality, Field 31C (Date of Issue) is the temporal anchor for the entire documentary credit lifecycle. It determines the validity period, the presentation window, the shipment deadline calculation, and the basis for maturity date computation. A single character error in this field mutates the entire compliance architecture of the credit.

Failure Mode Analysis

Failure Mode 1: Format Mismatch Between Field 31C and Document Dates

The credit issuance date in Field 31C uses format "YYMMDD" (e.g., 260715 for 15 July 2026), but the commercial invoice presents the date as "15 July 2026" or "2026-07-15." Under ISBP 745 Paragraph A16, dates may be expressed in any format provided the date intended can be determined. However, when the formats create ambiguity — particularly with dates where day and month could be transposed (e.g., 07/08/2026 could be 7 August or 8 July) — the bank may reject the presentation as discrepant under UCP 600 Article 14(d), which requires data not to conflict.

Failure Mode 2: Issuance Date Later Than Expiry Date

Field 31C (Date of Issue) is recorded as 15 July 2026, but Field 31D (Expiry Date) is recorded as 10 July 2026. This creates a temporal paradox: the credit expires before it is issued. Under UCP 600 Article 6(d)(i), the credit must have an expiry date for presentation. A credit that expires before issuance is a nullity — the bank's undertaking is illusory from inception. The nominated bank must refuse the credit as issued, or the issuing bank must amend.

Failure Mode 3: Field 31C Date Conflicts with Underlying Contract Date

The credit shows an issuance date of 15 July 2026, but the underlying sale contract is dated 1 August 2026. Under UCP 600 Article 4(a), "A credit by its nature is a separate transaction from the sale or other contract on which it may be based. Banks are in no way concerned with or bound by such contract." However, when the applicant or issuing bank uses the issuance date to calculate presentation periods, a future-dated contract creates confusion about when the 21-day presentation period under Article 14(c) begins.

Failure Mode 4: Field 31C Contains Non-Numeric Characters

Field 31C is populated with "15JUL2026" instead of the SWIFT-standard "YYMMDD" format (260715). SWIFT field formats are prescriptive — a non-conforming entry may cause the message to be rejected by the SWIFT network before it reaches the nominated bank. The credit never arrives, and the beneficiary is unaware.

Failure Mode 5: Field 31C is Blank or Missing

The credit is issued without Field 31C. Under UCP 600 Article 6(a), "A credit must state the bank with which it is available or whether it is available with any bank." While the article does not explicitly require Field 31C, the absence of an issuance date makes it impossible to calculate the expiry date, the presentation period, or the shipment deadline. The credit is defective from issuance.

Deterministic Resolution Architecture

1. Extract Field 31C immediately upon receipt. Do not defer. The issuance date is the first data point to verify — it anchors every subsequent calculation.

2. Validate the format against SWIFT MT700 specification. Field 31C must be in "YYMMDD" format. No exceptions. If the field contains a different format, flag it as a system-level error before it reaches the document examination stage.

3. Cross-reference Field 31C with Field 31D (Expiry Date). The expiry date must be on or after the issuance date. If Field 31D precedes Field 31C, the credit is temporally defective. Calculate: Field 31D >= Field 31C. If this inequality fails, the credit cannot be advised.

4. Calculate the presentation window. From Field 31C, compute the expiry date (Field 31D) and the latest shipment date (Field 44C or Field 44D). Verify that the shipment date precedes the expiry date, and that the 21-day presentation period under Article 14(c) is mathematically feasible.

5. Verify consistency across all dates in the credit. Field 31C must not conflict with Field 44A (Place of Taking in Charge), Field 44B (Place of Final Destination), Field 44C (Latest Date of Shipment), or Field 44D (Shipment Period). Any conflict violates UCP 600 Article 14(d).

6. Document the verification. Record the Field 31C value, the cross-reference results, and the calculation of the presentation window. This creates an audit trail for dispute resolution.

7. Communicate any discrepancy immediately. If Field 31C is missing, blank, or inconsistent, notify the issuing bank via MT799 or equivalent. Do not advise the credit until the deficiency is remedied.

8. Archive the validated Field 31C. Store the issuance date in the credit file as the baseline for all subsequent period calculations. Any amendment to the credit must be cross-referenced against this original date.

Conclusion

Field 31C is not a date — it is the temporal jurisdiction of the credit. Every period, every deadline, every presentation window flows from this single data point. The correct process is not "enter the date in the field." It is to extract the date, validate the format, cross-reference it against every dependent field, calculate the presentation window, and verify mathematical consistency across the entire credit.

The systemic failure mode is treating Field 31C as isolated data. It is not. It is the root node of a dependency graph that spans the entire documentary credit lifecycle. When this node is corrupted, every downstream calculation mutates.

FAQ

Q1: Can Field 31C be amended after the credit is issued?
Under UCP 600 Article 10(a), "Except as otherwise provided by article 38, a credit can neither be amended nor cancelled without the agreement of the issuing bank, the confirming bank, if any, and the beneficiary." Field 31C can only be amended through a formal amendment process. A unilateral correction by the issuing bank is not valid.

Q2: What if Field 31C shows a date that is a non-banking day in the issuing bank's country?
The issuance date is the date the credit is sent, not the date it is received. Under UCP 600 Article 2, a "banking day" is "a day on which a bank is regularly open at the place at which an act subject to these rules is to be performed." The issuance date need not be a banking day — it is the date of transmission. However, the presentation period and expiry date are calculated in banking days.

Q3: How does Field 31C interact with the 21-day presentation period under Article 14(c)?
Field 31C does not directly determine the 21-day period. The 21-day period is calculated from the date of shipment (as shown on the transport document), not from the issuance date. However, Field 31C establishes the expiry date (Field 31D), and the presentation must occur no later than the expiry date. The 21-day period and the expiry date create a dual constraint.

Q4: What happens if Field 31C is missing but all other fields are complete?
The credit is defective. Under UCP 600 Article 6(a)–(d), the credit must state essential terms including availability, expiry date, and place for presentation. While Article 6 does not explicitly list Field 31C, the absence of an issuance date makes it impossible to calculate the expiry date or the presentation period. The nominated bank should refuse to advise the credit until the deficiency is remedied.

Q5: Can Field 31C be in a format other than "YYMMDD"?
SWIFT MT700 specification mandates "YYMMDD" for Field 31C. A non-conforming format may cause the message to be rejected by the SWIFT network. If the credit is transmitted via a non-SWIFT channel (e.g., telex or email), the format may vary, but the date must still be determinable under ISBP 745 Paragraph A16.