What is negative interest rate processing testing?

Negative interest rate processing testing verifies that a banking system applies rates below zero according to the relevant product, contract and configured business rules. It checks the calculation, any rate floors or allowances, and the resulting account or loan postings. The expected treatment depends on the product: a negative rate may create a charge, be capped at zero, or follow another defined rule.

What negative interest rate processing testing covers

Testing should trace a rate from its source through calculation and posting. This can include rate configuration, customer or account eligibility, balance selection, accrual dates, day-count convention, rounding, and the final ledger entries or customer-facing transaction. Relevant systems may include a core banking platform, a loan servicing system and downstream statements or reporting.

Start by confirming the product rules and their precedence. For example, a product may have a negative benchmark rate, a contractual margin, a customer-specific rate floor and a balance allowance. The expected rate may depend on how these rules combine. Do not assume that every product applies the same floor or charges every customer in the same way.

The test oracle should use an independently calculated expected result or a separately reviewed calculation. Validate the system's intermediate values as well as its final amount, where those values are available. An incorrect rate, date range or sign convention can sometimes produce a plausible-looking posting.

Boundaries and calculation rules to exercise

Use [boundary value testing in banking] to select cases around the rules that change processing. Include a rate of zero, a small negative rate, the configured floor, and values immediately above and below that floor. Test balances at any allowance threshold, along with balances just either side of it. Include an eligible and an ineligible account where eligibility affects the outcome.

Calculation cases should cover the configured day-count convention, rate effective dates, repricing dates and rounding precision. Check periods that cross a month-end or year-end when those dates affect accrual. If the system supports backdated changes, verify recalculation and adjustment behaviour. A rate change should affect the correct accrual period and should not alter earlier periods outside the defined rules.

For an accrual with a fixed daily balance and simple interest, a useful reference calculation is:

interest = balance × annual rate × days / day-count basis

For example, a balance of £10,000 at -0.50% for 30 days on an ACT/365 basis gives £10,000 × -0.005 × 30 / 365 = -£4.109589.... If the product rounds the period amount to the nearest penny, the expected accrual is -£4.11. The test should then verify how that negative accrual is represented and posted under the product's sign and debit rules. This example assumes no compounding, rate floor or balance allowance.

Verify postings and downstream behaviour

Check that the calculated amount reaches the correct account and date, with the correct transaction type and sign. Where the design uses linked subledger and general ledger entries, verify that they balance and reconcile. Confirm that balances, transaction history and statements reflect the posting consistently. These checks help identify defects where the calculation is correct but the debit, account mapping or customer-visible amount is wrong.

Include failure and recovery paths. For example, test an accrual batch that stops part-way through and is restarted. Verify that completed entries are not duplicated and that incomplete work is handled according to the system's recovery rules. Check rejected or invalid rate configuration as well, including missing effective dates or a floor that conflicts with an allowed rate range.

Keep the environment and test data controlled. Record the product configuration, rate, balance, dates, day-count basis and rounding rule used by each case. If a downstream service supplies rates or receives postings, confirm the test uses the intended version and that environment drift has not changed the relevant configuration. [Banking day-count convention testing] and [banking rounding and precision testing] cover two calculation dependencies that often affect expected results.