What is traditional bank end-of-day regression testing?

Traditional bank end-of-day regression testing is the repeatable testing of established banking functions after a software, configuration or data change, using end-of-day processing to check that existing behaviour still works. It commonly exercises scheduled batch jobs that close the business date, post transactions and produce reconciliations or customer outputs across a bank's connected systems.

What the testing covers

End-of-day processing can include transaction posting, interest and fee calculations, balance updates, general ledger transfers, payment settlement, reconciliation, statement generation and business-date rollover. The exact scope depends on the bank's products, systems and batch schedule. Some processes run in sequence, with one job's output serving as another job's input.

Regression testing selects checks for behaviour that a change could affect. A change to an interest rule, for example, may require tests of interest accrual, account balances, ledger postings and statements. A scheduler change could also affect job ordering, restart handling or downstream files. The test scope should follow dependencies and business impact, rather than treating every batch job as equally exposed.

This is different from [banking batch processing testing], which focuses more broadly on batch execution characteristics such as throughput, scheduling and recovery. [Banking end-of-day processing testing] covers end-of-day behaviour itself; regression testing uses selected end-of-day scenarios to detect unintended change.

Preconditions and verification

A useful run needs controlled test data and a known business date. Prepare accounts, transactions, product rules, calendars and opening balances so the expected results can be calculated. Confirm that the environment has the relevant software and configuration versions, interfaces and reference data. Environment drift can make a failure hard to interpret or hide a defect.

Run the relevant jobs in their intended order, including dependent systems where the change could affect them. Verify job status and logs, then check business results: account balances, transaction postings, general ledger totals, reconciliation outcomes and generated files or statements. Compare results with approved expected values or a known-good baseline. Define in advance how to treat fields that change on each run, such as processing timestamps; exclusions should not hide differences in financial data.

A successful job status alone does not prove correct processing. A batch can complete while omitting records, applying a rule incorrectly or producing inconsistent downstream totals. Checks should therefore include both technical outcomes and business assertions. Where the processing design supports restart or rerun, test that behaviour and confirm that it does not create duplicate postings.

Worked example

Suppose a change is made to a savings account fee rule, while the existing end-of-day process also posts customer transactions and transfers totals to the general ledger. Set up an account with an opening balance of £1,000, a debit of £100 and a fee of £2 under the unchanged rule. Run the relevant end-of-day jobs for a fixed business date.

The regression checks should confirm a closing customer balance of £898, the expected debit and fee entries, and the corresponding ledger postings and reconciliation. They should also confirm that any statement or transaction output contains the expected entries. If the balance is correct but the fee is missing from the ledger, the test has found a regression that a balance-only assertion would miss.

Practical limits

End-of-day runs can have long dependency chains and may require large, representative data sets. A full run can take longer than the available test window, while a narrow run may miss interactions between products or systems. Risk-based selection helps focus execution on changed rules, affected interfaces and high-impact processes. Keep evidence of the tested software and configuration versions, business date, input data, job results and reconciliations so failures can be reproduced and release decisions can be reviewed.