Mortgage affordability rule change testing is the verification of revised lending rules that determine whether an applicant can afford a mortgage and, where applicable, how much they may borrow. It checks that the new policy is implemented correctly across calculations, decision outcomes, application channels and downstream systems, while existing cases continue to follow the intended rules.
Define the change before writing tests
Turn the approved policy into explicit, testable conditions. Identify which inputs and calculations have changed, which remain unchanged, and when the revised rules apply. Depending on the bank's policy and jurisdiction, inputs might include verified income, regular expenditure, existing credit commitments, interest-rate assumptions, loan term and repayment type. Avoid assuming that a policy has a single affordability threshold: it may contain several interacting conditions or permitted exceptions.
Record the rule version, effective date, affected products and application states. Clarify whether the change applies according to the date an application is submitted, assessed, offered or amended. Also agree expected outcomes for incomplete data, manual referrals and applications already in progress. If these points are ambiguous, raise them with the policy owner before treating test results as evidence of compliance.
Build decision coverage
Represent the policy as a decision table or equivalent rule model. List conditions as inputs and outcomes as decisions, such as pass, decline, refer for review or request more information. Include combinations that exercise each decision path, interactions between conditions, and boundary values immediately below, at and above relevant limits. This is useful when a rule change affects several inputs or exception paths.
Create controlled test data so that each case isolates the condition under test. Check units, frequency and currency conversions, rounding, missing values and the source of each input. For example, a monthly commitment must not be compared with an annual income value without the intended conversion. Verify the calculation independently from the application under test, using an approved rule specification or reviewed reference calculation as the oracle.
A simple hypothetical example might be a revised policy that refers an application when the calculated monthly surplus is below £250. Test cases should cover a surplus just below £250, exactly £250 and just above £250, with all other inputs held constant. The expected outcome at the boundary must come from the approved specification. The figures here illustrate test design only, not a lending recommendation or regulatory requirement.
Test the changed rule and its dependencies
First, run focused tests against the affordability calculation and decision service. Assert both the computed values and the resulting decision, including referral reasons where these are part of the output. Check that the rule version used is the intended one and that the system does not silently use stale configuration after deployment or a cache refresh.
Then test affected integrations and customer workflows. Follow relevant income and expenditure data from capture or document processing through validation, calculation, decisioning and any offer or referral output. Verify that API fields, stored results and user-facing explanations stay consistent. Where a workflow uses a manual review queue, check that the referral reason and supporting values reach the reviewer correctly.
Run regression tests for unchanged products, customer types and decision paths. Compare results with the previous rule version using the same controlled cases, then review every changed outcome against the approved policy. A difference may be intentional, caused by a defect, or produced by unrelated environment drift such as changed reference data or configuration. Use a stable environment and record relevant versions so these causes can be distinguished.
Check data, failure paths and evidence
Include negative cases for invalid, missing, duplicated or contradictory affordability inputs. Check how the system handles unavailable external data and calculation errors: it should follow the specified fallback or referral path rather than produce an unsupported approval. Confirm that retries do not create duplicate decisions and that a failed calculation does not leave a partial or misleading result.
For each case, retain the rule version, input data, expected and actual calculations, decision, timestamps and relevant logs or screen evidence. Link cases to the policy requirements and defects. This lets reviewers trace a result to the exact rule and identify which applications or workflows need retesting after a fix.
A release decision should consider more than passing calculation tests. Confirm that changed outcomes have been reviewed, affected integrations and regression cases have passed, and unresolved defects have an agreed impact assessment. This is particularly important when the rule is configuration-driven, because a technically successful deployment can still activate the wrong version or effective date.
Frequently asked questions
How should a bank test applications submitted before a rule change but assessed afterwards?
The bank should first obtain an approved policy for which rule version applies to each application state and date. Tests should then cover representative in-flight cases and confirm that the system selects the specified version without silently recalculating earlier decisions.
What is the difference between affordability testing and credit score testing?
Affordability testing checks whether an applicant's income and commitments support the proposed repayments under the bank's rules. Credit score testing checks a separate credit-risk assessment; the two may feed the same lending decision, but passing one does not establish that the other is correct.
Should mortgage affordability rule changes be tested with production customer data?
Use approved synthetic or suitably anonymised data where possible, with realistic relationships between income, expenditure and commitments. If production-derived data is necessary, follow the bank's data protection and access controls and verify that sensitive information is protected in test evidence.
How can teams detect that the wrong affordability rule version is active?
Include the expected rule version in test assertions and capture the version applied to each decision. Run cases across the changeover boundary and verify configuration, deployment and cache behaviour in the target environment.