What is variable-rate loan repricing testing?

Variable-rate loan repricing testing verifies that a loan servicing system applies contractual interest-rate changes at the correct time and calculates the resulting interest, repayment schedule and account updates accurately. Tests cover the rate source and repricing rules, the effective date, calculation conventions, customer-level eligibility and downstream processing, using expected results derived from the loan terms.

What variable-rate loan repricing testing covers

A variable-rate loan may use an external reference rate plus a contractual margin, or a rate set by the lender. Its terms determine when a rate is reviewed, which rate value applies, how a floor or cap affects it and when the change becomes effective. A rate movement does not necessarily trigger an immediate customer change: the contract may specify a review date, notice period or delayed effective date.

Testing checks that the system follows those rules for each eligible loan. It should verify the rate recorded before and after repricing, the effective date, the interest accrued for each relevant period and any revised instalment or amortisation schedule. Where applicable, it should also check customer communications, account history and financial postings.

The calculation depends on configuration and contract terms, including the day-count convention, rounding precision, compounding method and treatment of partial periods. A test oracle should use the same stated rules independently of the application under test. Comparing two screens that use the same calculation service may reproduce the same defect rather than detect it.

Preconditions and dependencies

A reliable test needs representative loan records with known principal balances, repayment terms, rate type, margin, floors or caps, reset frequency and next repricing date. It also needs a controlled rate input, such as a test reference-rate feed or an approved fixture, plus a defined business calendar and processing date.

Dependencies can include rate-feed interfaces, batch schedules, the loan ledger, payment scheduling and customer-notification services. Tests should establish which component owns each result and confirm that the data passed between systems agrees. Environment drift, stale reference rates, calendar differences or inconsistent configuration can make a valid test appear to fail, so capture the input rate, processing date and relevant configuration with the evidence.

How to test repricing outcomes

Cover the normal reset path and boundary conditions. Useful cases include a rate increase and decrease, an unchanged rate, a rate that reaches a contractual floor or cap, a reset on a non-business day, and a rate change near a payment date. Include ineligible or closed loans where the business rules require them to be excluded. Check repeated processing as well: rerunning a repricing batch should not apply the same change twice or create duplicate postings.

For each case, assert the selected rate and effective date, then independently calculate interest for the affected period. Verify the revised payment amount or schedule where the product rules require recalculation. Check that existing accrued interest is handled according to the contract, and reconcile the loan account and any associated ledger entries. An API assertion or database check can support these checks, while a customer-facing workflow can confirm that the displayed rate and payment agree with the servicing record.

Worked example

Assume a loan has a principal balance of £100,000, an annual rate that changes from 4% to 5%, and a 30-day interest period using an actual/365 day-count basis. For a simple interest calculation, the expected amounts are:

• At 4%: £100,000 × 0.04 × 30 / 365 = £328.77, rounded to the nearest penny.
• At 5%: £100,000 × 0.05 × 30 / 365 = £410.96, rounded to the nearest penny.

The expected difference is £82.19. This example checks the rate and period calculation only. A production loan may use a different convention, balance basis, compounding rule or rounding stage, so the test must follow the product’s documented terms. If the reset takes effect part-way through an accrual period, calculate each rate segment separately where the contract requires it.

Repricing testing and regression testing

Repricing testing focuses on whether a rate change is processed correctly for a loan. Regression testing checks whether a change to rate tables, calculation logic, batch processing or integrations has affected existing behaviour. A regression suite should retain representative fixed-rate and variable-rate products, boundary cases and previously defect-prone rules, with expected results tied to the relevant product configuration.

Treat a difference in rate, effective date, interest, instalment or posting as a defect candidate until the input data and contractual rule are confirmed. Evidence should make the result reproducible by recording the loan terms, rate input, processing date, calculation basis and system outputs.