How to test mortgage affordability calculations

Mortgage affordability calculation testing checks that a mortgage system derives a customer's available income and expected repayments correctly, then applies the lender's configured affordability rules to produce the right outcome. It verifies calculation logic, input handling, decision boundaries and the consistency of results across the application journey. Expected outcomes must come from approved product rules and requirements, since affordability policies vary by lender and product.

Define the calculation and its inputs

Start by mapping each requirement to its inputs, calculation and decision. Depending on the lender's rules, inputs may include verified income, tax and other deductions, regular expenditure, existing credit commitments, dependants, proposed loan amount, term and interest rate. Record the source, frequency, currency and treatment of each value. For example, check whether income is monthly net income or converted from an annual figure.

Separate the repayment calculation from the affordability decision. The repayment may be calculated using an amortisation schedule, while the decision compares that payment with an affordability limit derived from income and expenditure. Test each stage independently, then verify that the application passes the correct values between them.

Create an approved reference calculation, such as a spreadsheet reviewed against the business rules or a small independent test oracle. Avoid using the application code as its own expected result. If the rules include a stressed interest rate, specific expenditure assumptions or a minimum remaining-income buffer, encode those explicitly in the expected results.

Design calculation and boundary tests

Use Boundary value testing in banking to select cases around each decision threshold. Include values below, exactly at and above the limit. Cover zero and negative values where the input rules define their handling, as well as maximum permitted values, missing fields and invalid formats. Check that rounding follows the specified stage and precision; a rounded display value should not silently replace a more precise value used in the decision.

Test rule combinations with a decision table when the outcome depends on several conditions. For example, vary income type, existing commitments and product stress rate to confirm each condition affects the decision as specified. Add cases for changes in term or rate, since these can change the expected repayment even when the customer's income remains constant.

Use controlled mortgage application workflow testing to check that the result reaches the right decision and customer-facing summary. At integration level, verify that income and liability data received from upstream services is mapped to the correct fields, units and customer. These checks connect calculation testing with wider financial services testing.

Worked example with an explicit rule

Assume a test policy defines available monthly income as net income minus existing commitments, essential expenditure and a fixed buffer. It approves the proposed payment when that payment is less than or equal to the available amount. These figures illustrate test design only; they do not represent a general lending policy.

For net income of £4,200, commitments of £650, essential expenditure of £1,500 and a buffer of £250, the available amount is £1,800. With an independently calculated proposed payment of £1,800, the expected decision is pass. A payment of £1,800.01 should fail under this rule. A payment of £1,799.99 should pass. The test should also assert the calculated available amount and the reason code or decision detail, where required, rather than checking only the final pass or fail result.

Prepare reliable test data and verify outcomes

Build data sets that cover single and joint applicants, variable or irregular income, different payment frequencies, existing debts and missing or delayed external data. For a joint application, follow the defined rules for combining income and expenditure, and check that values are not counted twice. Use synthetic or appropriately protected data, with known expected results and stable identifiers for repeatable runs.

Run calculation tests against the service or component that owns the rules, then include integration tests through the application programming interface (API) and user journey where those paths exist. Verify the response fields, decision status, calculation breakdown and audit data against the same case. Compare results across relevant environments to detect configuration drift, such as a different rate or rule version.

When a case fails, inspect input mapping, rule configuration, precision, rounding, stale test data and downstream display separately. Preserve the rule version, input values, expected result and actual result as test evidence. This makes a changed outcome easier to assess after a rule update and supports targeted regression testing in banking.