Overdraft interest calculation testing

Overdraft interest calculation testing verifies that a banking system calculates and posts interest on an overdrawn account according to the product's approved terms. It checks the eligible balance, applicable rate, accrual period, day-count convention and rounding rules, then confirms that the resulting amount is recorded and presented correctly.

What overdraft interest calculation testing covers

The calculation depends on product configuration and account activity. A system may accrue interest daily from an end-of-day debit balance, apply a rate tier or an agreed overdraft allowance, and post the total at a statement date. The governing terms determine which balance and dates count, whether interest compounds, and when amounts are rounded.

Testing should establish those rules before deriving expected results. Relevant inputs can include transaction value dates, the effective dates of rate changes, the agreed limit, the annual rate, the day-count convention and the posting schedule. If a rule is unclear, an expected result cannot be treated as authoritative until the product owner or business specification resolves it.

The scope can include both the calculation and its downstream effects. Check that the interest amount reaches the account ledger, appears in the appropriate statement or transaction history, and is included correctly in any relevant balance or reporting output. Where systems exchange the result, verify that the amount and effective date remain consistent across those interfaces.

How to verify the calculation

Use controlled test data with a known opening balance and a small number of transactions. Keep the expected calculation independent of the system under test, for example in a reviewed test oracle or a separately implemented calculation. Comparing two outputs from the same calculation service can repeat the same defect rather than detect it.

Include ordinary cases and rule boundaries. Useful cases include an account moving from credit to debit, a balance at or around a rate-tier threshold, a rate change during an accrual period, a transaction with a different value date, and a period containing a leap day if the configured convention makes that relevant. Test zero or negative eligible balances, the agreed overdraft limit and any configured allowance or threshold. Confirm the expected treatment from the product rules rather than assuming all overdrafts use the same method.

Check precision at each relevant stage. A system that rounds each day's accrual can produce a different total from one that sums unrounded daily amounts and rounds only when posting. Verify the configured approach, decimal precision and currency rules, including the displayed amount and ledger posting. Small differences can also arise when the reference calculation uses a different day-count denominator or date inclusion rule.

A failed test may come from incorrect business logic, stale product configuration, an incorrect value date, mismatched test data, or environment drift between the calculation service and the account ledger. Preserve the input transactions, effective configuration, expected calculation and observed postings so the source of a discrepancy can be isolated.

Worked example

Assume a test product specifies simple daily interest on a constant eligible debit balance, a 12% annual rate, a 365-day denominator and rounding to the nearest penny only when interest is posted. The account has an eligible debit balance of £500 for 10 accrual days, with no transactions or rate changes.

The expected unrounded amount is £500 × 0.12 × 10 ÷ 365, or approximately £1.6438. The expected posted interest is £1.64. The test should confirm the accrual interval and balance used, the posted amount, and the resulting account entries. This example applies only to the stated hypothetical rules; a real product may use different balance, date, rate or rounding rules.