Mortgage bank fixed-rate expiry workflow testing verifies that a mortgage moves through the correct servicing steps when its fixed-rate period ends. It checks eligibility, timing, customer communications, rate selection, payment recalculation and downstream records against the loan contract and the bank's configured rules. The workflow may run from a scheduled batch, an event or a staff action, depending on the system design.

Define the workflow and its expected outcomes

Map the process from the source mortgage record to the final account state. Confirm which system owns the contractual rate end date, how the expiry is detected, and which services receive the resulting update. A workflow may involve loan servicing, customer communications, a digital banking channel, payment scheduling and accounting records.

Document the permitted outcomes for each product and customer choice. Depending on the mortgage terms and bank rules, the loan might move to a variable rate, a new fixed rate, or another agreed arrangement. Record the effective date, rate source, payment treatment and any required approval or customer instruction for each path. Avoid assuming that every mortgage follows the same route.

Set preconditions in test data, including the product, balance, rate end date, payment frequency, repayment type and any relevant customer instruction. Include records that should be excluded, such as a mortgage already redeemed, where the bank's rules require exclusion. Keep test data isolated from live customer communications and financial processing.

Design end-to-end scenarios

Cover the main successful paths and the boundaries around the expiry date. Test a mortgage approaching expiry, one due to expire on the processing date, and one already past that date. Include a run before and after the configured processing window. Verify that the workflow handles the bank's business calendar and time-zone rules consistently.

Test customer decisions separately: a valid selection made before the cut-off, no selection received, a selection submitted after the cut-off, and an amended or cancelled instruction. Check that the system applies the permitted outcome and records which instruction or rule determined it. Add negative tests for missing rate data, incomplete mortgage records, invalid instructions and a downstream service being unavailable.

For each case, assert the mortgage's state, rate, effective date and next payment schedule in the system of record. Verify that customer correspondence contains the correct product and dates, and that the digital channel shows the same status. Where accounting or reporting systems receive updates, check that their records reconcile with the servicing record. This is end-to-end testing across the relevant applications, rather than a check of the expiry screen alone.

Check rate and payment calculations

Use the contract's calculation rules and approved reference values to verify the new payment amount. Inputs may include the outstanding principal, applicable rate, remaining term, repayment method and payment frequency. Confirm the applicable day-count, rounding and effective-date rules where they affect the result. Compare the system output with an independently calculated expected result or an approved calculation service.

Check that the old rate applies up to the contractual end point and the new rate starts on the correct date. Validate the first payment after the change, including any part-period treatment specified by the product. A correct rate with an incorrect effective date can still produce an incorrect statement or payment instruction.

Practical test case

Assume a test mortgage has a fixed rate ending on 30 September, monthly repayments and a valid customer instruction to move to a new fixed product from 1 October. Configure the agreed new rate and expected payment in the test environment.

Run the expiry workflow for 30 September. Verify that the mortgage retains its old rate through the contractual end date, adopts the selected rate from 1 October, and receives the expected revised payment schedule. Check that the instruction is recorded, the customer confirmation shows the same effective date and rate, and any connected servicing or accounting record reflects the update. Run the workflow again for the same processing window and confirm that it does not create a second rate change or duplicate communication.

Verify recovery, controls and evidence

Test how the workflow behaves when a downstream system times out or rejects an update. Confirm that the case is visible for retry or manual handling, that a retry does not duplicate a rate change, and that the mortgage does not appear complete while required updates remain outstanding. Reconcile the processing population against completed, excluded and failed cases so that missed records are detectable.

Retain evidence that links the mortgage test data, triggering event or batch, expected result, actual state changes and any messages or errors. Review access controls for staff actions that can override an expiry outcome, and verify that changes are attributable to an authorised user or system process. These checks support repeatable [end-to-end testing in banking] and [mortgage servicing] regression coverage.

Frequently asked questions

How should test teams handle mortgages with more than one loan part?

Model each loan part with its own rate, expiry date, balance and payment terms, then verify whether the bank processes each part independently or as a combined customer workflow. Check that an instruction for one part does not change another part unintentionally.

How can teams keep expiry tests safe in a shared test environment?

Use isolated test customer records, non-production communication endpoints and controlled payment or accounting integrations. Before execution, confirm that batch schedules and message routes cannot reach live customers or trigger real collections.

What evidence helps investigate an expiry workflow defect?

Capture the source mortgage values, processing date and time, triggering event or batch identifier, applied rule, customer instruction, resulting state changes and downstream responses. Correlate records with a trace or transaction identifier where the systems provide one.

When should expiry workflow tests run in a release cycle?

Run focused scenarios after changes to rate rules, date handling, mortgage servicing, customer instructions or connected systems. Include broader regression coverage when a release changes shared batch processing, payment scheduling or customer communications.