Most bank guarantee UAT plans test issuance, amendment, and a straightforward demand-and-pay cycle — and then declare the module ready. What they rarely test properly is the extend-or-pay demand: the moment a beneficiary, instead of asking for immediate payment under a guarantee, asks the issuing bank to either extend the guarantee's validity or pay out. This single mechanism, governed by URDG 758 Article 17, is where a surprising share of production incidents in demand guarantee modules originate.
Why This Demand Type Gets Skipped in UAT
Extend-or-pay demands are less frequent than straightforward demands, so test teams under time pressure often deprioritise them — treating them as an edge case rather than a core lifecycle event. But URDG 758 makes extend-or-pay a standard beneficiary right, not an exception. A demand guarantee module that cannot handle it correctly is not URDG 758 compliant, regardless of how well the standard issuance and demand flows perform.
Extend-or-pay is not an edge case in the guarantee lifecycle. It is a standard right under URDG 758 — and a module that mishandles it is not compliant, no matter how clean the rest of UAT looks.
What a Complete Extend-or-Pay Test Plan Needs
A test plan that actually covers this mechanism needs to validate the full decision chain the issuing bank must execute on receipt of the demand:
- Applicant notification and response window — the system must correctly compute and track the time the applicant has to instruct the bank on whether to extend or pay, and what happens on silence.
- Default-to-pay behaviour — if the applicant does not respond within the stipulated period, most guarantee texts default to payment. Test that the system enforces this default rather than leaving the guarantee in limbo.
- Partial extension scenarios — where the applicant agrees to extend for a shorter period than the beneficiary requested, and the beneficiary must decide whether to accept or demand payment on the original terms.
- SWIFT MT768/MT769 messaging — the acknowledgment and advice messages tied to extension decisions, and their correct sequencing against the demand.
- Counter-guarantee cascade — where the guarantee sits under a counter-guarantee structure, an extend-or-pay decision on the primary guarantee has downstream implications on the counter-guarantee that must also be tested, not assumed to follow automatically.
Where This Actually Breaks in Production
The failure pattern is consistent across implementations: the system correctly processes a straightforward demand end-to-end, but when an extend-or-pay demand arrives, the workflow either misroutes it as a standard demand (skipping the applicant notification step entirely) or stalls waiting for an instruction type the workflow was never configured to expect. Both failure modes surface only when a real beneficiary exercises this right — which, by definition, does not happen in the majority of guarantees issued, making it exactly the kind of gap that survives UAT and reaches go-live undetected.
Building This Into Your UAT Plan
The fix is not more test cases in general — it is specific test cases for this mechanism, built against the actual guarantee text templates your bank issues, not generic URDG 758 language. Test data should include guarantees with explicit extend-or-pay clauses, guarantees silent on the mechanism (where URDG 758 default rules apply), and guarantees under counter-guarantee structures where the cascade must be traced end to end.
A demand guarantee module that has never processed an extend-or-pay demand in UAT has not been tested against URDG 758 — it has been tested against a simplified version of it. Bankly's URDG 758 test case pack builds this mechanism in as a first-class scenario set, not an appendix.