How to test a building society savings-to-mortgage journey

Building society savings to mortgage journey testing verifies that a customer can use savings towards a mortgage deposit through the relevant applications and services, with each system showing the correct customer, account, balance, permissions and transaction state. It is end-to-end testing across savings and mortgage processes, governed by the society's product rules and the agreed journey design.

Map the journey and its systems

Start by documenting the customer actions and system hand-offs. Depending on the society's architecture, the journey may involve an online banking channel, a savings account platform, mortgage origination, a payment service and a mortgage servicing or core system. Confirm which systems own each decision and record; do not assume a savings account is automatically linked to a mortgage application.

Capture preconditions and expected outcomes for each stage. These may include customer identity matching, savings account ownership, withdrawal permissions, available funds, evidence of deposit, mortgage application status, transfer authorisation and the final mortgage completion state. Make product-specific rules explicit. For example, access to notice accounts or cash individual savings accounts (ISAs) may follow different rules, so tests should use approved requirements rather than assume that all savings can be withdrawn in the same way.

Define the interfaces as well as the screens. Agree which customer and account identifiers pass between systems, how a transfer is requested and confirmed, what status events are sent, and how errors are reported. Include timing expectations where a process is asynchronous, such as a transfer that remains pending until a downstream service confirms it.

Prepare controlled test data

Use synthetic or appropriately masked records with clear relationships between customer, savings account, mortgage application and transaction. Include accounts with sufficient and insufficient available balances, different withdrawal conditions, and customer records that do not match across systems. Keep data consistent across applications and resettable between runs.

Record the environment and data state before execution. Environment drift, stale customer records, unavailable test payment services or mismatched product configuration can cause failures that resemble application defects. Where a live third-party service is unsuitable for testing, use an agreed simulation and test the integration contract separately.

Test the happy path and failure paths

For a successful journey, verify more than the final confirmation page. Check that the correct savings account is selected, the permitted amount is available, the mortgage application receives the required deposit evidence, and the transfer is authorised and recorded once. Reconcile the resulting balances and transaction references across the systems that own those records. Confirm that the mortgage progresses only when its documented conditions are met.

Exercise failures at each hand-off. Examples include a withdrawn or restricted savings account, insufficient available funds, a customer identity mismatch, a rejected transfer, a timeout after submission, and a duplicate retry. Check that the mortgage application does not advance incorrectly, the savings balance is not debited twice, and the customer receives an accurate status. If a transfer can be reversed or cancelled, verify that the reversal updates all affected records and leaves an auditable history.

Also test interrupted journeys. A customer may leave after authorising a transfer, return in another channel, or resume after a pending status changes. Verify that the application displays the current state and that repeated actions do not create duplicate requests. Use stable selectors and assertions against meaningful status or transaction data in automated tests, rather than relying solely on page text or fixed wait times.

Worked example

Given a synthetic customer with an eligible savings account and an approved mortgage application, request a deposit transfer for £10,000. Before the request, capture the savings available balance and the mortgage application status. After confirmation, assert that the transfer has one unique reference, the savings balance reflects the authorised transaction, the mortgage application records the deposit evidence, and the application advances only if its specified conditions are satisfied.

Repeat with an account that has less than £10,000 available. The expected result should state whether the request is blocked or handled another way under the product rules. In either case, assert that no unauthorised debit occurs and that the mortgage state remains accurate. The values and expected statuses in this example are test inputs, not universal product rules.

Verify evidence and diagnose failures

Keep evidence that links the test case to the customer, account, application, transfer reference, system responses and final assertions. Compare interface events with persisted records where access permits. A green user-interface test alone does not prove that downstream balances and application states agree.

Classify failures by layer: test data, environment, user interface, service contract, business rule or persistence. Then rerun with the same controlled data to establish whether the result is reproducible. This makes it easier to distinguish a genuine journey defect from a dependency or setup issue, and supports focused regression testing when a savings or mortgage component changes.