Risk-based testing for mortgage banks

Risk-based testing for mortgage banks is a way to choose and prioritise tests according to the potential impact and likelihood of failures in mortgage products, processes and supporting systems. It directs more testing effort towards outcomes such as incorrect affordability decisions, inaccurate loan balances, missed arrears actions or faulty property releases, while retaining coverage of lower-risk functions and required controls.

How to apply risk-based testing for mortgage banks

Start with the mortgage journeys and business outcomes in scope. Map the systems and interfaces involved, such as the application portal, loan origination system, credit decision service, valuation provider, document platform, servicing system and general ledger. A journey map helps identify failures that may sit between applications rather than within one component.

Identify risks from requirements, architecture, defects, incidents, operational procedures and conversations with mortgage, compliance and technology specialists. Consider customer and financial harm, legal or regulatory exposure, data confidentiality, operational disruption and the difficulty of detecting or correcting an error. The relevant obligations depend on the jurisdiction, product and business model, so map applicable requirements with the bank's compliance and risk teams. Risk-based prioritisation does not remove the need to test mandatory controls or agreed requirements.

Assess each risk using a documented scale. For example, a team might rate impact and likelihood as low, medium or high, then use the combined assessment to set test priority. Define what each rating means and record the evidence behind it. A high-impact risk with uncertain likelihood may still warrant substantial coverage, particularly where the bank has limited production evidence or the failure would be hard to reverse.

Translate each prioritised risk into test conditions, expected results and evidence. Use appropriate methods, including decision-table testing for lending rules, boundary-value testing for thresholds, and end-to-end testing for journeys across systems. For automated checks, assert business outcomes through reliable interfaces or data comparisons where available. A successful screen transition alone does not show that a decision, balance or accounting entry is correct.

Mortgage risks to assess and test

For origination, examine affordability inputs and calculations, credit decision rules, applicant and property data, document handling, offer generation and approval permissions. Test values around policy thresholds, missing or conflicting evidence, and changes to an application after an initial decision. Confirm that a decision uses the intended data and rule version, and that any required human review or approval step occurs.

For completion and servicing, cover the hand-off from accepted offer to drawdown, including amount, rate, term, payment date and account setup. Check that servicing calculations agree with approved terms. For a rate change, verify the effective date, revised instalment, customer communication and downstream accounting. For redemption or collateral release, test eligibility, outstanding amounts, fees where applicable, approvals and the resulting status across connected systems.

Also assess non-functional and control risks where they could affect mortgage outcomes. Examples include unauthorised access to applicant records, loss of an audit trail, processing delays around a completion date, and recovery after an interrupted batch. Include failure paths such as a valuation service timeout or an incomplete document upload. Verify that the process retries safely, raises the right exception and avoids creating duplicate or inconsistent records.

Worked example: affordability rule change

Suppose a change updates the treatment of a particular income type in an affordability calculation. The team records the affected products, decision rules, interfaces and downstream processes, then rates the risks. An incorrect calculation could lead to an unsuitable lending decision, so the calculation and its decision outcome receive high priority.

Create tests for an applicant just below the relevant affordability threshold, one at the threshold and one just above it. Add cases for missing income evidence and an application that contains conflicting values from two sources. Check the calculation against independently approved expected results, confirm the resulting decision and review status, and verify that the decision and rule version are recorded. Run relevant regression tests for other income types and products that use the same calculation component. If the test environment uses stale rules or reference data, resolve that dependency before treating a failure or pass as reliable.

Review priorities and release evidence

Record the risk, affected requirement or control, selected tests, results, defects and any accepted residual risk. Link evidence to the relevant release so reviewers can see what was tested and what remains unresolved. A risk rating should guide test selection, while release decisions should also consider failed tests, unresolved defects, environment limitations and the bank's approval process.

Reassess priorities when requirements, product rules, integrations, data sources or architecture change. A previously low-risk component can become significant when it feeds a high-impact decision. Use defect trends and production incidents to challenge assumptions, and document why any planned test was deferred or excluded. This keeps the rationale understandable to delivery teams, risk owners and auditors.