UCP 600

UCP 600 Article 35: Message Authentication

📅 2026-07-13 5 min read UCP 600 / ISBP 745

Introduction

Message authentication in the context of UCP 600 Article 35 concerns the bank's responsibility for the integrity and verification of SWIFT messages and other electronic communications used in documentary credit operations. Article 35's disclaimer — that banks assume no liability for the form, sufficiency, accuracy, genuineness, falsification, or legal effect of any document — extends to the messages that transmit credit instructions, amendments, and documentary data. When a bank receives a SWIFT MT700 (issue of a documentary credit) or MT799 (free-format message), the authentication of that message is governed by the SWIFT network's security protocols, not by UCP 600. Article 35 reinforces that the bank's liability does not extend to the genuineness or content of messages it receives through the SWIFT network, even when those messages form part of the documentary presentation.

Failure Mode Analysis

Failure 1: Bank relies on SWIFT authentication without verifying content. SWIFT's authentication framework verifies that a message originated from the stated BIC and was transmitted securely. It does not verify that the content of the message is accurate. A bank that accepts an authenticated SWIFT message without checking its content against the credit terms is not meeting the Article 14(a) examination standard.

Failure 2: Free-format MT799 messages accepted without verification. MT799 free-format messages are not structured and do not carry the same field-level validation as MT700 messages. A bank that accepts an MT799 as a valid amendment or waiver without verifying its consistency with the credit is exposed to risk. Article 35 does not protect the bank from accepting content it should have examined.

Failure 3: Message received after presentation deadline. When a SWIFT message arrives after the credit's expiry or presentation deadline, the bank must determine whether the message is part of the presentation or an independent communication. Article 35's disclaimer does not override the timing requirements under Article 14(c).

Failure 4: Duplicate message handling. When the same SWIFT message is received multiple times (due to network errors or retransmission), the bank must determine whether each receipt constitutes a separate presentation. Article 35 disclaims liability for network errors, but the bank must still apply its examination procedures.

Failure 5: Message content contradicts paper documents. When a SWIFT message (e.g., an MT700) specifies terms that contradict paper documents in the presentation, the bank must resolve the inconsistency under Article 14(d). Article 35 does not shield the bank from the obligation to identify and address contradictions.

Deterministic Resolution Architecture

  1. Identify the message type. Determine whether the SWIFT message is an MT700 (credit issue), MT701 (continuation), MT707 (amendment), MT799 (free-format), or another type. The message type determines the examination approach.

  2. Verify SWIFT authentication. Confirm that the message passed SWIFT's authentication checks. This verifies the sending BIC and transmission integrity, not the content accuracy.

  3. Examine the message content against the credit. Apply Article 14(a) to examine the message on its face. Check that the credit terms in the MT700 match the paper documents presented.

  4. Resolve inconsistencies under Article 14(d). If the message content contradicts other documents, identify the conflict and determine whether the presentation is complying.

  5. Apply timing rules. Determine whether the message is part of the presentation or an independent communication. Apply Article 14(c) timing rules to the message receipt.

  6. Document the examination. Record the message type, BIC, date, content summary, and any discrepancies found. Preserve the examination record.

  7. Refer to Article 34 for transmission issues. If the message was lost, delayed, or mistranslated, apply Article 34 rather than Article 35. The two provisions address different issues.

Conclusion

Message authentication under UCP 600 Article 35 operates at the intersection of SWIFT security protocols and the bank's document-examination obligation. Article 35 disclaims liability for the genuineness and accuracy of messages, but it does not eliminate the obligation under Article 14(a) to examine messages on their face. Banks must verify content consistency, resolve contradictions, and apply timing rules — even when the message itself has passed SWIFT authentication. The most common error is treating SWIFT authentication as a substitute for content examination.

FAQ

Does SWIFT authentication replace the bank's examination obligation? No. SWIFT authentication verifies the sending BIC and transmission integrity. It does not verify content accuracy. The bank must still examine the message content under Article 14(a).

Can an MT799 free-format message amend a credit? An MT799 can carry amendment information, but the bank must verify its consistency with the credit terms. Article 35 does not eliminate the obligation to examine the message content.

What if a SWIFT message arrives after expiry? The bank must determine whether the message is part of the presentation and apply Article 14(c) timing rules. Article 35 does not override the expiry-date requirement.

Does Article 35 apply to fax or email messages? Yes. Article 35's disclaimer applies to all documents, regardless of format. SWIFT, fax, email, and other electronic communications are subject to the same disclaimer.

How does eUCP address message authentication? Under eUCP Version 2.1, Article e9, electronic records (including SWIFT messages) are subject to the same examination standard as paper documents. The bank examines the electronic record on its face.


Source Notes

Context only — no deep source text was extracted from the original research feeds.

Did You Know?

Article 14(a) examination standard.

Regulatory Reference Table
RegulationArticle / SectionRequirementConsequence
UCP 600Article 35Disclaimers on Transmission and TranslationBinary determination (compliant/discrepant)
UCP 600Article 14Standard for Examination of DocumentsBinary determination (compliant/discrepant)
UCP 600Article 34Disclaimers on DocumentsBinary determination (compliant/discrepant)
UCP 600Article 24Road, Rail or Inland Waterway Transport DocumentsBinary determination (compliant/discrepant)

← Scroll horizontally to see all columns

Quick Reference Summary

  • No reference captured.

Compliance Checklist

0 of 7 completed

Get the Full LC Compliance Checklist

15-point pre-submission checklist covering UCP 600, ISBP 745, and SWIFT MT700 fields. Free PDF download.

No spam. Unsubscribe anytime.

DraftLC Compliance Engine

DraftLC generates compliant UCP 600 Article 35 — so you never face this failure mode.

DraftLC drafts your LC with UCP 600-compliant terms and flags conflicts during drafting — before documents reach the bank.

No credit card required · See how DraftLC drafts compliant credits