Chapter 098: Testing Finance Systems

Section 20: Finance Data, Change Delivery and Practical Capstones · Chapter 098 of 100

Bank accounting tests need independent expected journals, schedules, populations and reporting measures. This chapter proves those outcomes and tests recovery after work has already committed or settled.

1. Chapter opening

Finance-system testing must establish correct accounting and complete processing, not just stable screens or balanced journals. Use unit, integration, accounting-schedule, population, reconciliation, reporting, performance and recovery checks appropriate to the change. The exact sequence and breadth are risk-based; build representative boundary cases and independently derived expected results.

2. Learning objectives

  1. Write journal-verification test cases (expected debits/credits/dimensions/dates).
  2. Design reconciliation test packs (tie-outs with seeded breaks).
  3. Run parallel closes (new vs legacy) with difference attribution.
  4. Build reporting regression suites (cell-level stability across changes).
  5. Define go-live gates (evidence thresholds, rollback readiness).

3. Business context

Test the risks that affect bank balances and customer obligations. Synthetic data can deliberately cover rare boundaries and support privacy; lawfully governed production-derived data can reveal real distributions and integration defects. Neither automatically guarantees coverage. Compare the cost of testing with evidenced risk reduction rather than invented 10×fix or 60–70%defect statistics. A legacy system is a useful comparator, not proof of correct accounting.

4. Finance and accounting view

4.1 An independent journal oracle

Assume a retained IFRS 9 loan has gross carrying amount 100 and revised contractual cash-flow PV95 at its original EIR, after an approved asset-retention decision. Expected journal: Dr Modification loss 5 / Cr Loan gross carrying amount 5. ECL is reassessed separately. For a PV105 case, Dr Loan 5 / Cr Modification gain 5. Do not prescribe only a debit-to-loan catch-up for every amendment. Test signed terms, calculation assumptions, recognition date, currency, legal entity, dimensions, rule version and accepted journal identity.

For ordinary previously accrued interest 10 and principal 100 received: Dr Cash 110 / Cr Interest receivable 10 / Cr Loan 100. Income was recognised at accrual; receipt does not credit income again. Test same-bank deposit payment separately because cash does not move externally. A replay after lost acknowledgement must return the original outcome, and a reversal/correction must preserve its original reference.

4.2 Schedules, stages and reporting

Reproduce an EIR from explicit cash flows and verify principal, accrued interest, fee/cost adjustments and allowance bridges. Market-rate reset, prepayment estimate, modification and credit loss require distinct rules. A Stage 1→Stage 2 change does not cause gross-to-net interest recognition; a qualifying post-origination credit-impaired asset uses the required net basis in subsequent reporting periods, and POCI uses a credit-adjusted EIR. Test the timing and facts, not a generic “any stage transfer switches net” assertion.

Reports can change intentionally when taxonomy or definitions change. Compare stable semantics and populations, not only identical old/new cells. Seed missing, duplicate, misclassified and wrongly netted events; a total that ties after two offsetting errors should fail the item/population tests.

4.3 Boundaries, independence and recovery

Derive expected results from contracts, approved policy and authoritative requirements, using an independent calculation method and review proportionate to risk. Organisational separation strengthens independence but is not a universal prohibition on developers writing meaningful tests. Avoid copying production code into the oracle. Resolve disputed outcomes with the accounting owner rather than changing the expected result to match implementation.

Cross period-end, holiday, rate reset, backdated capture, lock state, volume and feed failure where those combinations can change accounting. Retain known untested high-risk combinations with accountable treatment. Recovery tests must cover committed journals, partial external settlement, migration membership and forward corrections as well as database restore. A restore cannot undo a settled payment or erase required audit evidence.

5. Product and customer impact

Test customer balances, interest, charges, statements and legal effective dates under realistic disruptions. Communications and complaints follow actual conduct obligations; proactive notification does not automatically turn a reportable complaint into a non-complaint. Hypercare supports operations but does not excuse known material balance defects.

6. Regulatory and supervisory view

Apply actual supervisory change, resilience, model-validation, outsourcing and data requirements to the affected system. The course’s test layers and example exit criteria are control designs rather than globally mandatory law. Keep unresolved material accounting defects visible at readiness review; obtain proper approval and remedies under the bank’s applicable rules.

7. Systems and data view

Preserve source versions, masked/synthetic dataset provenance, reference calendars, policy inputs, test oracle calculations, journal/report results, coverage, defects and retests. Pseudonymised production data may remain personal data; masking is not automatically lawful anonymisation. Apply an appropriate basis, access/minimisation/retention controls and additional sensitive-data requirements. Archive enough evidence to reproduce tested versions.

8. End to end process

  1. Identify affected accounting and operational risks.
  2. Design populations, boundaries and independent expected outcomes.
  3. Prepare lawful representative data.
  4. Execute journal, schedule, reconciliation and reporting tests.
  5. Investigate differences and independently retest repairs.
  6. Prove performance and committed-event recovery.
  7. Review readiness and retain scope limitations.

9. Controls and risks

RiskControlEvidence
Happy-path-only coverageEdge-case matrix sign-offCoverage packs
Oracle repeats implementation errorIndependently derived expected outcomes and risk-appropriate reviewCalculation, policy source and review evidence
Untested rollbackMandatory rollback drillDrill packs
Gate pressure overrideEvidence-threshold enforcementGate records

10. Practical examples

**Combined boundaries:**200 base cases plus 40 combined cases produce 7 failures (4 period-lock,2 calendar,1 duplicate). Fix and rerun, then add 12 new cases: total 252, not 240. A clean rerun proves those scenarios/versions; it does not certify that production will have zero defects or assign an unsupported 60–70%probability to untested cases.

Income variance: a 0.3% difference implies 12m/year only if the affected comparison base is 4bn/year (4bn×0.003). Specify that base and reconcile the actual convention; do not equate a rate difference with a percentage of income without units.

Recovery: restore test records, re-establish accepted journal identities, reconcile already settled payments and process necessary forward adjustments. Demonstrate that a retry does not double-post committed work.

11. Diagrams

Figure 1. Finance testing layers. Finance testing layers Figure 2. Acceptance dimensions. Acceptance dimensions Figure 3. Duplicate-event test. Duplicate-event test

12. Tables

TestExpected evidence
Modification PV95 from 100Dr Loss 5 / Cr Loan 5, separate ECL
Accrued repayment 110Clear receivable 10 and principal 100, no extra income
Stage 1→2Lifetime-ECL assessment, no generic net-interest switch
Qualifying credit-impaired/POCICorrect fact-specific interest basis and timing
Replay/recoveryOne accounting effect per authorised event
Taxonomy changeAttributed semantic/population changes

13. Illustrative bank case study

The close was untested. In this fictional bank, transaction tests passed while allocation, intercompany and report-mapping interactions had no complete close-cycle evidence. Parallel testing exposed the gaps, and the team repaired them before authorising the final operating procedure. No real bank’s restatement, outage or enforcement outcome is asserted.

14. BA, developer, tester and operations guidance

  • BA: specify exact journal/date/balance outcomes and semantic measures.
  • Developer: build traceable event effects and committed-work recovery.
  • Tester: use independently derived oracles and explicit boundaries.
  • Operations: test close procedures and retain meaningful exceptions.

15. Common mistakes

  1. Treating balanced journals or the old system as proof of accuracy.
  2. Copying implementation into the test oracle.
  3. Switching net interest for every stage change.
  4. Counting added tests incorrectly.
  5. Calling masked data automatically anonymous.
  6. Treating restore as cancellation of legal settlement.

16. Key takeaways

Prove contracts, accounting measures, population completeness and recovery with independent expected results. Report actual coverage and limitations instead of claiming absolute error-free production.

17. References and verification notes

  • IFRS 9: accounting classification/impairment and prudential risk measures are separate; use endorsed period version.
  • BCBS 239: 14 principles:11 bank-focused plus 3 supervisory; scope and domestic application need assessment. No prescribed universal database, staffing or response deadline.
  • ICO lawful-basis guide: current UK guidance updated 2 April 2026 lists seven lawful bases, including recognised legitimate interest; select the applicable basis and additional conditions rather than assuming consent is universal.

Fictional cases and thresholds. Tests are proportionate control designs; actual accounting policy and applicable supervisory/data requirements determine acceptance.