Most banking system implementations get the complying presentation flow right. Documents arrive, the system examines them, payment goes out. That path is well-tested. What is routinely missed is everything that happens when documents do not comply the first time — the discrepancy notice, the applicant waiver, the second presentation, the revised utilisation tracking. That is where LC systems break in production, and where UAT plans carry the widest gaps.
What "Second Presentation" Actually Means
When an issuing or nominated bank receives documents under a Letter of Credit and finds them discrepant, it has a specific set of options under UCP 600 Article 16. It can hold the documents and seek a waiver from the applicant. It can return the documents to the presenter. Or it can act on prior instructions from the presenter.
If the discrepancy is waived and documents are accepted — or if the presenter corrects the discrepancy and re-submits — what follows is effectively a second presentation against the same LC. The system must correctly:
- Track the previous presentation and its status in the audit trail
- Re-open the presentation workflow against the same LC reference
- Recalculate available balance (LC amount minus prior utilisation)
- Re-run the 5 banking day examination clock from the new receipt date
- Link the second presentation to the first for reporting and history
None of this is exotic. It is standard LC operations. But in most UAT plans, only the first complying presentation gets a test case. The second presentation scenario — with all its state transitions — is absent.
The Four Reasons Presentations Come Back
1. Document discrepancy — UCP 600 Article 14
The most common cause. Invoice description does not match LC field 45A. Bill of Lading is presented beyond the 21-day window (Art. 14c). Quantity shown is outside the 5% or 10% tolerance (Art. 30). Certificate of Origin issued by the wrong authority. Each of these generates a discrepancy notice (MT734) and potentially a corrected re-submission.
Stale Bill of Lading (Art. 14c), partial shipment against NOT ALLOWED LC (Field 43P), invoice description mismatch (Art. 18c), MT734 discrepancy notice generation and transmission.
2. The 5 banking day window — and what happens when it expires
UCP 600 Article 16b gives the bank a maximum of 5 banking days from receipt to examine documents and send a discrepancy notice. If the bank fails to send MT734 within that window, it loses the right to claim discrepancy. This is one of the most consequential provisions in the UCP — and one of the most consistently untested in UAT.
Your system must enforce this. It must alert the examining officer when Day 4 passes with no decision. It must require supervisor override if a discrepancy notice is attempted on Day 6 or later. Most systems have this logic in their specification. Most UAT plans do not test whether it actually works.
A bank that misses the 5 banking day window and then attempts to raise a discrepancy notice on Day 6 is legally exposed under UCP 600. The beneficiary or presenting bank can argue the issuing bank has waived its right to claim discrepancy and is obligated to pay. This is not theoretical — it has been subject to litigation and ICC opinions.
5 banking day examination timer overdue alert (Art. 14b). Discrepancy notice attempted on Day 6 — system requires supervisor approval, high-risk alert raised, action documented in audit trail.
3. Applicant waiver — the MT752 flow that most plans skip
The applicant receives the discrepancy notice (MT734) and decides the commercial relationship matters more than the document irregularity. They waive. The issuing bank then sends MT752 to the nominated or negotiating bank authorising payment despite the discrepancy. The system must record the waiver reference, update presentation status from DISCREPANT to ACCEPTED, and initiate the payment flow.
This is a positive path — and it is frequently absent from test plans because testers assume discrepancy means rejection. That is not what UCP 600 says and it is not what happens in most live transactions.
Applicant waives discrepancy — presentation status changes from DISCREPANT to ACCEPTED, MT752 generated to negotiating bank authorising payment (UCP 600 Art. 16e). Waiver reference and date recorded.
4. Partial utilisation — the running balance problem
An LC for USD 200,000 permits partial shipments. First presentation: USD 80,000 — accepted and paid. Second presentation: USD 100,000. The system must know that USD 120,000 remains available, accept the second presentation, and update the running utilisation register. Third presentation: USD 20,000 — LC fully utilised and closed.
Where implementations fail: the utilisation tracking when the first presentation went through a discrepancy-waiver cycle before payment. The state transitions in that path — PRESENTED → DISCREPANT → WAIVED → ACCEPTED → PAID — can produce incorrect balance calculations when the second presentation is registered. It is precisely this sequence that UAT plans rarely test.
Second partial presentation against ALLOWED LC. LC USD 200,000. First presentation USD 80,000 accepted. Second presentation USD 100,000 — system validates USD 120,000 available, accepts presentation, updates running utilisation to USD 180,000. Both presentations visible in LC history.
What Your UAT Plan Should Cover
At minimum, your LC test plan needs these second-presentation scenarios explicitly scoped:
- Discrepancy raised → applicant waiver → payment (MT752 flow) — the most common real-world path after a non-complying presentation
- Discrepancy raised → documents returned → presenter corrects and resubmits — the true second presentation scenario
- 5 banking day timer expiry alert and supervisor override — enforce it in the system, not just document it in policy
- Partial utilisation: second and third presentations — including after a waived discrepancy on the first presentation
- LC balance at zero after all presentations — confirm LC status moves to FULLY UTILISED and closes correctly
If your current LC test plan covers only the single complying presentation path, you have tested the easy case. You have not tested the system your operations team will actually run — where the first presentation is discrepant more often than it is clean.
The Bankly LC pack (v2.0) covers 138 test cases across 7 modules — LC Issuance, Amendment, Document Presentation, Discrepancy Handling, Payment & Acceptance, Closure, and SWIFT Message Validation. All scenarios are aligned to UCP 600 and built from real implementation and operations experience.