Across banking implementations in India, South Africa, and Europe, the pattern is consistent: the production incidents that cause the most damage trace back to scenarios that were never in the UAT plan. Not because they were hard to write. Because the team writing them did not know enough about the domain to know the scenario existed.
The Three Most Common Test Case Mistakes
1. Testing the happy path and calling it done
A complying LC presentation. A successful NEFT transfer. A KYC application that passes every check. These are important to test — but they are the easiest scenarios to get right. A system that only passes happy path testing has been tested for the 30% of transactions that work perfectly. It has not been tested for the 70% that don't.
Every banking domain has a set of boundary conditions and edge cases that only appear when you know the underlying regulation. The 5 banking day rule under UCP 600. The irrevocability of settled RTGS. The SMA-0 classification trigger at day 1 of overdue. These are not edge cases from an operations perspective — they are everyday events that happen thousands of times a year in any bank. They are only "edge" in a test plan written without domain knowledge.
2. Test case titles that describe the UI, not the business rule
Compare these two test case titles:
- "Verify that the Submit button is enabled after all mandatory fields are filled."
- "Verify that a Letter of Credit cannot be issued when the applicant's credit limit is insufficient, and that the system generates a limit breach alert per the bank's credit policy."
The first is a UI test. It tells you the button works. The second is a domain test. It tells you the credit control works. Both are valid — but a test plan full of the first type and short on the second type will pass UAT and fail in live operations when the credit limit is breached and the system issues the LC anyway.
Each test case is written from the business rule, not the UI. Pre-conditions set the exact state. Expected results reference the specific regulation, limit, or processing rule — not just "system accepts" or "system rejects".
3. Missing the negative and boundary scenarios
Most test plans have a 70/30 split — 70% positive scenarios, 30% negative. In banking, that ratio should be closer to 50/50. The negative and boundary scenarios are where regulatory compliance lives. The LC amount that is 1% over tolerance. The payment that hits the UPI daily limit exactly. The KYC document that expired yesterday. The STR filing that misses the 7-day deadline by one day.
These scenarios require the tester to know the rule in order to construct the boundary. A 5% tolerance on LC amount is UCP 600 Article 30. A ₹1 lakh daily UPI limit is an NPCI regulation. A 7-day STR filing deadline is PMLA Section 12. Without that knowledge, the boundary is invisible and the test case is never written.
The most common cause of post-go-live incidents in banking system implementations is not a technical defect — it is a scenario that was not tested because it was not in the test plan because nobody on the UAT team knew the relevant regulation well enough to write it.
What Domain-Driven UAT Looks Like
Start with the regulation, not the screen. For every module, ask: what are the rules governing this process? What happens when each rule is violated? What are the boundary conditions? Write a test case for each. Then cross-reference with your functional specification to confirm coverage.
A domain-driven LC test plan starts with UCP 600 and ISBP 821. A domain-driven AML test plan starts with PMLA and FATF 40 Recommendations. A domain-driven payments test plan starts with RBI's NEFT/RTGS/UPI operating guidelines. The regulation is the test plan outline. The test cases fill it in.