What is term deposit maturity testing?

Term deposit maturity testing verifies that a fixed-term deposit reaches its maturity state on the correct date and that the bank applies the configured rules for interest, repayment, rollover or other maturity instructions. It checks the full outcome across account records, payment or renewal processing, customer communications and accounting entries, using the product’s contractual terms as the expected result.

What term deposit maturity testing covers

A maturity event depends on more than the calendar date. Tests should verify how the system derives that date from the deposit start date and term, including the configured treatment of weekends, public holidays, month ends and leap years. The applicable business calendar and date cut-off rules should be explicit. Where systems use different time zones or business dates, verify which date triggers processing.

Check the deposit’s state before and after maturity. For example, a deposit might move from active to matured, then close after the principal and interest are paid. Other products may renew automatically or wait for an instruction. Expected behaviour depends on the contract and product configuration, including any grace period or customer election window.

Financial assertions should cover the principal, accrued interest, applicable rate, day-count convention, compounding and rounding rules. If tax or fees apply, include them according to the product rules. Verify the final amount and the individual components used to calculate it, so a correct-looking total does not conceal an incorrect interest calculation.

Maturity processing can cross application boundaries. Check that the core banking record, customer account balance, general ledger postings, transaction history and statement or notification data agree. For a rollover, verify the new deposit’s principal, term, rate and start date against the maturity instruction and applicable product rules.

Designing reliable maturity tests

Use test data that gives control over the deposit’s start date, term, rate, instruction and status. Include ordinary dates alongside boundaries such as month end, year end, leap day and a maturity date falling on a non-business day. Include deposits with different maturity instructions and verify that ineligible, closed or otherwise invalid records follow the specified exception path.

Make time controllable in the test environment where possible. A test can set the business date or invoke the maturity batch for a selected processing date, avoiding a wait for a real calendar date. Confirm that the batch selects deposits due on that date, leaves future maturities untouched and records failures with enough detail for investigation.

Test reruns and partial failures. If a batch stops after posting some maturity events, restarting it should follow the defined recovery behaviour and avoid duplicate customer credits, ledger entries or rollover accounts. Verify both the successful records and the rejected or retried records.

Worked example

Assume a test product specifies a 90-day term, a 4% annual simple interest rate, a 365-day basis, interest rounded to two decimal places and payment of principal plus interest at maturity. For a principal of £10,000, the expected interest under those assumptions is £10,000 × 0.04 × 90 ÷ 365, rounded to £98.63. The expected payment is £10,098.63 before any separately configured deductions.

Set up a deposit whose maturity date matches the test business date. Assert that the deposit matures once, the customer account receives the expected amount, and the ledger entries balance according to the posting rules. Run the maturity process again and check that it does not create a second payment. This example is a test oracle for the stated assumptions; production expectations must come from the relevant product terms and configuration.

For broader lifecycle coverage, pair this work with [Deposit rollover testing] and [Banking day-count convention testing].