UAT sign off checklist for fintech releases: the one we use
Our UAT (user acceptance testing) sign off checklist for fintech releases records six decisions before go-live: business owners accepted each money flow on real-like synthetic data, UAT runs reconciled with no unexplained difference, customer notices were verified, open defects carry financial impact, rollback was rehearsed, and named signers approved with evidence retained.
Adrian Voss, Lead QA engineer, payments and acquiringPublished Updated
What UAT sign off means, by definition
The ISTQB Glossary defines user acceptance testing (UAT) as "A type of acceptance testing performed to determine if intended users accept the system." It defines acceptance testing as "A test level that focuses on determining whether to accept the system." We read both entries on 2026-09-22. Neither says who accepts a payment or lending release, or what proof they keep. Our checklist fills that gap: each row has a pass condition and a retained evidence record.
The glossary defines severity as "The degree of impact that a defect has on the development, testing or operation of a component or system." ISTQB revised that definition on 2026-06-06. A severity label does not state what an open defect costs per affected account, so our defect section asks for the amount and its basis.
Why a fintech UAT pass rate is not enough
A green UAT pass rate hides three failure patterns we check for:
- The screen passes and the ledger fails. A partial refund shows the right app balance and reduces the wrong instalment; reconciling the UAT run against expected postings exposes it. The procedure is in our ledger reconciliation testing guide.
- A fee change ships ahead of its notice window. Regulation E, 12 CFR 1005.8(a)(1), requires a financial institution to "mail or deliver a written notice to the consumer, at least 21 days before the effective date" of a change to a term disclosed under 1005.7(b) that would increase the consumer's fees or liability, reduce the types of available electronic fund transfers, or tighten limits on transfer frequency or dollar amount. Paragraph (a)(2) exempts an immediate change "necessary to maintain or restore the security of an account or an electronic fund transfer system." Regulation Z, 12 CFR 1026.9(c)(2)(i)(A), requires written notice "at least 45 days prior to the effective date" of a significant change on open-end credit plans that are not home-equity plans, "except as provided in paragraphs (c)(2)(i)(B), (c)(2)(iii) and (c)(2)(v)". In the EU, PSD2 Article 54(1) requires changes to a framework contract to be proposed "no later than 2 months before their proposed date of application"; under Article 54(2), interest or exchange rate changes "may be applied immediately and without notice" where the contract agrees that right and the changes follow the agreed reference rates.
- Open defects are ranked without money. A Minor defect that collects 40.00 early on every affected order can cost more than a Major defect on an internal report.
The checklist we use
This checklist is our practice; no regulation prescribes it in this form. Copy the six tables into the release ticket at UAT entry and close each row with a link to its evidence. Test amounts use XTS, the ISO 4217 code reserved for testing, and synthetic data replaces real account data in every row.
A. Business acceptance of money flows
| ID | Check | Pass condition | Evidence kept |
|---|---|---|---|
| A1 | Each money flow has a named business owner | One owner per flow in the UAT plan | UAT plan |
| A2 | Synthetic data mirrors production balances, currencies, fee tiers, and limits | No production customer data in UAT | Data set ID and masking scan result |
| A3 | Each flow runs end to end, from initiation to statement and customer message | Actual amounts equal amounts computed before the run | Expected-result sheet and run log |
| A4 | Decline, reversal, full and partial refund, and timeout with retry run | Each path ends in a documented state with correct balances | Run log per path |
| A5 | Month end, cut-off time, bank holiday, and leap day run where accrual or fees change | Amounts equal the expected sheet to the minor unit | Expected-result sheet |
| A6 | UAT fee, rate, and limit configuration equals the release candidate | Configuration diff is empty or approved | Diff file with SHA-256 hash |
B. Reconciliation of UAT runs
| ID | Check | Pass condition | Evidence kept |
|---|---|---|---|
| B1 | Each UAT transaction appears in the ledger, the simulator file, and the customer balance | Three-way match per transaction ID | Reconciliation report |
| B2 | Totals match per currency and value date | Unexplained difference equals 0 minor units | Totals report |
| B3 | Each difference has a cause | Each break links to a defect ID or a documented timing item | Break list |
| B4 | Duplicate postings are searched for | Zero duplicates by idempotency key and transaction ID | Query and output |
| B5 | Fee and interest totals match the expected sheet | Equal to the minor unit | Fee and interest reconciliation |
| B6 | Reconciliation reruns after the last fix | Rerun on the build ID that goes live | Rerun report |
C. Customer-facing disclosures and notices
| ID | Check | Pass condition | Evidence kept |
|---|---|---|---|
| C1 | Each changed fee, rate, limit, or term has a notice | Each change maps to a notice ID | Change-to-notice map |
| C2 | Notice timing meets the applicable rule and its exceptions | Send date precedes the effective date by the required period, such as 21 days (12 CFR 1005.8(a)), 45 days (12 CFR 1026.9(c)(2)), or 2 months (PSD2 Article 54(1)) | Notice schedule |
| C3 | Notices, receipts, and statements show ledger amounts and dates | Values match in app, email, and PDF statement | Rendered file per channel |
| C4 | Product disclosure text equals the approved text | Version IDs match | Approved text with version ID |
| C5 | Notices render per locale in scope | Language, currency, and date formats are correct | Rendered sample per locale |
| C6 | Compliance owner reviewed C1 to C5 | Signed and dated | Review record |
D. Open defects by severity with financial impact
| ID | Check | Pass condition | Evidence kept |
|---|---|---|---|
| D1 | Each open defect has severity, flow, and status | No blank fields | Defect log export |
| D2 | Each open money-flow defect states financial impact | Amount per affected item, items at risk, and basis present | Defect log with financial impact |
| D3 | Each open defect that touches a rule names the clause | Clause reference present | Defect log |
| D4 | Our release gate: zero open Blocker or Critical defects in money flows | Count equals 0 | Filtered defect log |
| D5 | Each deferred defect has a workaround, owner, and fix date | All three present | Deferral record |
| D6 | Business owner accepts the total exposure of deferred defects | Signed total amount | Exposure acceptance record |
E. Rollback readiness
| ID | Check | Pass condition | Evidence kept |
|---|---|---|---|
| E1 | A rollback runbook exists for this release | Trigger conditions, steps, and owner stated | Runbook with version |
| E2 | Rollback is rehearsed on the release build before production | Rehearsal completed with timestamps | Rehearsal log |
| E3 | Transactions created on the new version complete on the old version | Posting, refund, and reconciliation pass after rollback | Test log |
| E4 | Schema migrations are backward compatible or have a tested down migration | Old version runs on the migrated schema | Migration test log |
| E5 | Feature flags stop new money flows without a deployment | New items blocked, in-flight items complete | Flag test log |
| E6 | Each in-flight payment state has an end state after rollback | Every state maps to completion or reversal | In-flight state map |
F. Who signs, and the evidence retained
| ID | Check | Pass condition | Evidence kept |
|---|---|---|---|
| F1 | Business owner of each flow signs section A and row D6 | Name, role, date, build ID | Sign off record |
| F2 | Finance or reconciliation owner signs section B | Name, role, date, build ID | Sign off record |
| F3 | Compliance owner signs section C | Name, role, date, build ID | Sign off record |
| F4 | QA lead signs rows D1 to D5 and the evidence index | Name, role, date, build ID | Sign off record |
| F5 | Release owner signs section E | Name, role, date, build ID | Sign off record |
| F6 | The evidence index links every row to its file | Path, SHA-256 hash, build ID, environment, run date, and signer | Evidence index |
| F7 | Evidence is stored read-only for the client's records retention period | Location and retention end date recorded | Storage record |
How we run the checklist
- Blank rows block sign off. A row that does not apply is marked "N/A" with a one-line reason that the section signer approves.
- One build ID covers all six sections. A fix after sign off reopens B6, D1, and E2 for the new build, and every signer re-signs.
- Defect impact follows the defect log format shown in the sample on our dedicated QA team page.
- The evidence index doubles as audit input. An auditor who later samples the change asks for the same records, which our audit and certification test evidence service builds. Other Regulation E notice rules are on our Regulation E testing requirements page.
Sources
- ISTQB Glossary, term "user acceptance testing" (UAT), version 4, used in CTFL v4.0,
- ISTQB Glossary, term "acceptance testing", version 2, keyword in CTFL v4.0,
- ISTQB Glossary, term "severity", definition revised 2026-06-06,
- eCFR, 12 CFR 1005.8, Change in terms notice; error resolution notice (Regulation E), current text, last substantive amendment 2017-01-01,
- eCFR, 12 CFR 1026.9, Subsequent disclosure requirements (Regulation Z), current text, last substantive amendment 2022-04-01,
- Directive (EU) 2015/2366 on payment services in the internal market (PSD2), Article 54,
Related
Segments
Standards
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing