What UCP 600 Test Cases Need to Cover
UCP 600 — the Uniform Customs and Practice for Documentary Credits — governs how letters of credit work internationally. Every LC implementation on a core banking platform must reflect UCP 600 rules accurately: how documents are examined, what constitutes a discrepancy, how long the issuing bank has to examine presentation, and how SWIFT messages are generated at each stage.
Most UAT registers for LC modules test the happy path: an LC is issued, documents are presented, payment is made. What they miss is the document compliance layer — the rules under UCP 600 Articles 14–29 that govern what the bank must actually check when documents arrive. This is where production defects originate.
Core UCP 600 Test Scenario Areas
LC-UCP-001
Document examination period
Bank has maximum 5 banking days to examine documents after presentation (UCP 600 Art. 14). System must track the clock from receipt, not from presentation date.
LC-UCP-002
Complying presentation
Documents comply with LC terms, UCP 600, and ISBP 745. System must confirm all required documents present, within validity, and data consistent across documents.
LC-UCP-003
Discrepancy identification
Non-complying document triggers discrepancy flag. System generates SWIFT MT734 notice of refusal within the 5-banking-day window with specific discrepancy reason codes.
LC-UCP-004
Waiver processing
Discrepancy waiver requested from applicant. System tracks waiver status, approval, and payment release — or document return if waiver is refused.
LC-UCP-005
Partial shipment / drawing
UCP 600 Art. 31: partial drawings allowed unless prohibited. System must track cumulative drawing amount against LC value and enforce prohibition where stipulated.
LC-UCP-006
Expiry and presentation deadline
Documents must be presented within LC validity period and within 21 calendar days after shipment (UCP 600 Art. 14c). System must reject late presentations.
SWIFT MT700 Series Test Coverage
Every LC implementation generates SWIFT messages at key workflow stages. UAT must confirm that message content is correct, mandatory fields are populated, and field formats comply with SWIFT standards — not just that a message is sent.
- MT700 — LC Issuance: Field 40A (form of credit), 31D (expiry date/place), 50 (applicant), 59 (beneficiary), 32B (currency/amount), 41A (available with/by), 43P/43T (partial shipment/transhipment), 45A (description of goods) — all must be tested for content accuracy against the LC application
- MT707 — Amendment: Field 23 (reference to LC), changed fields flagged with tag 79. Amendment register must be updated. Beneficiary acceptance workflow where required.
- MT734 — Advice of Refusal: Must be sent within 5 banking days. Field 77J (discrepancy details) must carry specific, accurate discrepancy descriptions — not generic codes.
- MT750 — Advice of Discrepancy: Sent to issuing bank where negotiating bank identifies discrepancy. Must reference the original MT700.
- MT754 — Advice of Payment: Generated on payment authorisation. Field 32B (currency/amount paid) must match the complying presentation amount.
Common UAT Gap
SWIFT message content is frequently tested by confirming the message was sent, not by verifying field-level accuracy. Field 77J discrepancy descriptions carrying wrong or generic codes, MT700 field 45A carrying truncated goods descriptions, and MT707 amendment references pointing to wrong LC numbers are all defects that pass a basic UAT check and fail in production.
LC Variants That Need Separate Test Coverage
A single LC test pack that only covers the standard sight LC has not tested the module. Each variant has distinct rules that must be separately exercised:
- Usance LC: Deferred payment period — system must track maturity date from acceptance and generate payment on due date, not on presentation
- Transferable LC: UCP 600 Art. 38 — transfer to second beneficiary, split transfer, amendment rights of second beneficiary, and bank's right to refuse transfer
- Back-to-Back LC: Two separate LCs linked operationally — the master LC documents must align with the back-to-back LC terms; system must not auto-link the two
- Red Clause LC: Advance payment before shipment — system must track advance drawn and deduct from final payment; advance recovery on non-performance
- Standby LC: Governed by ISP98 rather than UCP 600 — demand mechanism is different; system must not apply documentary credit rules to standby demands
The Domain Knowledge Gap
Banking IT delivery teams implementing LC modules on Temenos, Finastra, Intellect, or custom builds have strong system knowledge. The test cases they write reflect what the system does. What is harder to write without banking domain experience is test cases that reflect what the system is supposed to do under UCP 600 — the rules, the timing, the document compliance logic, and the SWIFT field-level accuracy that a correspondent bank will check in production.
Bankly's LC test pack covers 138 test scenarios across 7 modules, built domain-first — from how LC actually works under UCP 600, not from how a system menu is configured.
138 UCP 600-aligned LC test cases — ready to use
Issuance · Amendment · Document examination · Discrepancy · Payment · SWIFT MT700 series · All LC variants
Get in Touch →