How to regression test tiered interest in a savings bank

Savings bank tiered interest regression testing checks that changes to account configuration, calculation code or connected banking services preserve the agreed interest outcome for every balance tier and accrual period. It compares calculated and posted interest with the product rules, including tier boundaries, rate changes, day-count conventions, rounding and crediting. The expected result must come from an approved specification or an independently calculated oracle.

Define the rules before testing

Confirm how the product applies its tiers. With marginal tiers, each rate applies only to the portion of the balance within that band. With whole-balance tiers, the rate for the applicable band applies to the entire balance. These models can produce different interest amounts for the same account.

Record the rules that affect the calculation: tier thresholds, rates and effective dates; the balance basis, such as daily closing balance; the day-count convention; the accrual and posting frequency; compounding; and the rounding point and precision. Confirm how the system handles deposits, withdrawals, backdated transactions, leap years and accounts that change tier during an accrual period.

Treat configuration as testable product behaviour. A code release can leave calculation logic unchanged while a rate-table or effective-date change alters customer outcomes. Include both code changes and relevant configuration changes in the regression scope.

Build regression scenarios around boundaries and change

For each tier boundary, test a balance below it, exactly at it and just above it using the bank's currency precision. For marginal tiers, verify the allocation of the balance across bands. For whole-balance tiers, verify which single rate applies. Add scenarios for a zero balance, a balance that crosses a tier after a transaction, and a balance that moves between tiers during the period.

Cover date and lifecycle behaviour as well. Test the first and last accrual day, a rate change part-way through a period, a leap-year date where relevant to the convention, and a posting run that is repeated or restarted. Include account eligibility, product-specific overrides and any minimum-balance conditions defined by the product.

Use controlled financial test data with known opening balances, transactions, rate tables and dates. Keep an independent calculation, such as a reviewed spreadsheet or a small reference function, separate from the production calculation code. Record the inputs and expected values so a failure can be reproduced after an environment refresh.

Worked example: marginal tiers

Assume a product pays 2% on the first £10,000 and 2.5% on the portion above £10,000. The account has a constant daily balance of £12,000 for 30 days. For this example, use an actual/365 convention, simple accrual and rounding to the nearest penny only when interest is posted.

The expected unrounded accrual is:

• £10,000 × 0.02 × 30 / 365 = £16.438356
• £2,000 × 0.025 × 30 / 365 = £4.109589
• Total: £20.547945, posted as £20.55

A regression test should assert the tier allocation and the posted result, as well as the account's accrued-interest value if that value is exposed. The test must use the bank's actual rules for rounding, day count and posting; changing any of those assumptions changes the expected result.

Check the full posting path

Verify that the calculation consumes the intended balance and rate configuration, then check the resulting accrual, customer account entry, interest subledger and general ledger output where those components are in scope. Reconcile totals across accounts for the test run. Confirm that statements or customer-facing views show the credited amount and value date specified by the product.

Run the same controlled scenarios against the previous and candidate builds where practical. Investigate differences against approved changes, and check for environment drift in rate tables, calendars, account settings and rounding configuration. A passing calculation assertion alone does not establish that interest was posted once, on the correct date, or represented consistently downstream.

Keep regression evidence with the rule version, test data, execution date, expected calculation and actual results. This makes failures easier to classify as calculation defects, configuration errors, data issues or downstream posting problems.