How to test tiered savings interest calculations

Tiered savings interest testing verifies that an account earns the correct interest when different portions of its balance qualify for different rates. Testing must follow the product's rules for tier structure, eligible balance, accrual dates, day-count convention, compounding and rounding. The expected result should come from an independent calculation that can be compared with the system's accrued and credited interest.

Confirm how the tiers work

A tiered rate can apply marginally, where each rate applies only to the balance portion within its tier, or to the whole balance, where the rate for a tier applies to the entire qualifying balance. These methods produce different results, so establish which one the product specifies before designing expected values.

Record the tier boundaries and rates, the balance used for eligibility, and how the system handles rates that change during an accrual period. Confirm whether interest accrues daily, which dates count, the day-count basis, the posting frequency, and when rounding occurs. Check how the product treats promotional rates, balance caps, account eligibility and closed or inactive accounts where those rules apply.

These details are dependencies for a reliable test. A mismatch may come from an incorrect rate rule, a transaction's value date, a calendar setting or a different rounding point. Treat the product specification and configured account terms as the source for expected behaviour.

Design boundary and calculation tests

Use [boundary value testing in banking] to test balances immediately below, at and above every tier threshold. For a currency balance, select amounts using the smallest permitted balance increment. Also cover zero balance, a balance within each tier, the highest tier, and any cap or eligibility limit. Include deposits and withdrawals that cross a threshold, with their effective dates represented in the test data.

Test representative accrual periods as well as boundaries. Useful cases include a constant balance, a balance change part-way through the period, a rate change, and a period that crosses a month or year boundary. Check the accrued amount separately from the amount posted to the account: posting frequency and rounding may make these values differ.

Build an independent oracle from the documented rules. Avoid reusing the production calculation code in the test oracle, since the same defect could then affect both results. Use decimal arithmetic with the applicable currency precision and freeze dates or provide an explicit calendar in automated tests.

Worked example

Assume a product uses marginal tiers and a 365-day denominator. The first £1,000 earns 1% per year, the next £4,000 earns 2%, and any balance above £5,000 earns 3%. For a constant balance of £6,000, the annualised interest is:

• £1,000 × 1% = £10
• £4,000 × 2% = £80
• £1,000 × 3% = £30

The annualised total is £120. For 30 days at that constant balance, the expected accrual before rounding is £120 × 30 ÷ 365, or approximately £9.8630137. The test should compare the system's result with this value, applying the product's specified rounding and posting rules at the correct stage.

For the £5,000 boundary, test £4,999.99, £5,000.00 and £5,000.01 if penny increments are permitted. The expected interest should change according to the marginal portion entering the next tier. A whole-balance product would have a different expected result and requires its own oracle.

Verify the result across the workflow

Assert the calculation output and any stored accrual, then check the credited transaction when the account reaches its posting date. Where the workflow exposes them, reconcile the account balance, transaction record and customer statement. An API response alone may confirm a calculation while missing a posting or display defect.

Run the same controlled cases after changes to rate tables, calendar configuration or calculation services. If results differ between environments, compare their product configuration, time zone, date source and test data before treating the discrepancy as a code regression. Keep the inputs, expected values and observed results as test evidence.