Traditional bank branch to mobile journey testing checks that a banking task started in a physical branch can be continued or completed in the bank's mobile application, with the correct customer, workflow state and data preserved across channels. It is a form of cross-channel, end-to-end testing that verifies the hand-off between branch processes and mobile services, including the systems that store and exchange customer and application information.

What traditional bank branch to mobile journey testing covers

A journey may begin when a customer discusses a product with a member of branch staff, submits an application or updates account details. The customer then uses the mobile app to upload documents, review information, provide consent or track progress. The test checks the complete business outcome, including how branch actions are recorded and made available to the customer.

The systems involved depend on the journey. They may include a teller or customer relationship management application, identity and document services, a mobile banking application, workflow services and core banking. Tests should identify the expected hand-offs and authoritative source for each important value, such as application status or customer contact details.

Typical checks include whether:

  • the mobile app finds the correct in-progress task for the authenticated customer;
  • branch-entered data and uploaded documents appear accurately in the app;
  • changes made in either channel are reflected in the relevant systems;
  • consent, eligibility and approval rules are applied consistently;
  • customers receive an accurate status when a task is pending or rejected.

The scope overlaps with [End-to-end testing in banking] and [Cross-channel banking consistency testing]. The first focuses on completing a business workflow across its systems; the second focuses on consistent data and behaviour across channels. A branch-to-mobile test may need both perspectives.

Preconditions and dependencies

Before execution, define how the branch action is linked to the mobile customer. The link may use a customer identifier, an application reference or another approved correlation method. Do not assume a branch workstation session carries over to a personal device. The customer may need to sign in again and complete the bank's normal authentication steps.

Use controlled test data for a known customer and a workflow in a suitable test environment. Confirm that branch, mobile and back-end services use compatible configurations and reference data. Environment drift, delayed messages, unavailable document services or different product rules can produce failures that resemble defects in the journey itself. Record these dependencies so the team can distinguish a product fault from an environment issue.

How to verify the journey

Check the customer-visible result and the persisted business state. A mobile screen showing an application as submitted is insufficient if the workflow service has not recorded the submission or the application has been linked to the wrong customer. Use approved API or service-level assertions, database checks where permitted, and audit records to confirm the transaction and its status. Avoid relying on a single user interface indicator as the sole proof.

A practical test case is a customer who starts a current account application with branch staff and completes document submission on mobile:

  1. Create a test customer and begin an application in the branch application. Record its reference and expected initial status.
  2. Sign in to the mobile app as that customer and open the pending application.
  3. Upload an accepted test document and submit it.
  4. Verify that the app confirms receipt, the application remains linked to the same customer, and the workflow records the document and expected status.
  5. Check the branch view or an authorised service-level record to confirm the update is visible to staff.

Also test failure paths that affect continuity: an expired mobile session, a duplicate submission, a delayed update or a document rejected by validation. Confirm that the customer receives an accurate message and can recover without creating an unintended duplicate application. This is especially relevant to [Mobile banking application testing], where device and app behaviour form part of the customer journey.

Common failure modes

A journey can appear successful while retaining stale data in one channel. Other failures include matching a task to the wrong customer, losing a branch-entered value during mobile submission, accepting a duplicate upload, or displaying a completed status before downstream processing finishes. Define expected behaviour for asynchronous updates, retries and interrupted journeys, then verify those outcomes using the relevant records and customer-facing messages.

Frequently asked questions

Does the customer need to stay in the same session when moving from branch to mobile?

No. The branch and mobile interactions usually use separate sessions. Testing should verify that the bank links the mobile user to the correct customer and pending workflow after the required sign-in and authentication steps.

Should branch-to-mobile tests use real customer data?

Use approved test data, such as synthetic or appropriately anonymised records, in a controlled environment. Avoid copying identifiable customer information into test systems unless the bank's data controls explicitly permit it.

What should a test check if the customer changes device part-way through the journey?

Verify that the customer can securely find and resume the same pending task on the new device, that saved data remains intact, and that the change does not create a duplicate application or weaken access controls.