Financial services

Planning a mobile financial-service experience

Solution experience

This solution draws on the BCT team’s hands-on experience. Scope and delivery arrangements are tailored to each project.

Planning a mobile financial-service experience

Solution Overview

This solution covers a mobile interface connected to a financial-service provider. The provider retains ownership of regulated processes and transaction rules; the software scope must be agreed with its technical and compliance teams.

The Challenge

Questions to resolve before committing to scope:

  • Which actions can the app initiate, and which require provider approval?
  • How are failed, delayed or repeated requests handled?
  • What information may appear on a shared or lost device?

Delivery approach

  • Agree on journeys and boundaries: Map sign-in, account information and supported requests against the provider’s API contracts.
  • Prototype against a test environment: Use test data to review confirmation screens, error recovery and session handling with stakeholders.
  • Verify before a staged release: Agree on security review responsibilities, release criteria, monitoring and rollback with the provider.

Inside the solution

From workflow to system design

  • Mobile UX
  • API integration
  • Session security
Reference architecture for Mobile UX, API integration, Session security. Design rationale and deliverables follow below.
Reference architecture showing the solution’s components and data flows. The implementation is adapted to each project’s requirements.
Explore interactive architecture ↗

Delivery model

Application development against the provider’s sandbox

Client decisions and discovery

The provider’s product owner defines supported journeys. Its security and compliance owners identify applicable requirements and approve transaction behaviour and release conditions.

BCT implementation responsibilities

The BA maps business rules to API operations with the provider. Engineers implement the mobile interface and recovery states. QA checks duplicate submissions, session expiry and sensitive-data exposure.

Review gates and scope boundaries

Maintain a requirements-to-test record and resolve gaps with the provider before release. The provider confirms applicable regulatory requirements and release approvals.

Key design decision

Keep financial decisions with the provider. Use stable request identifiers and explicit pending states; an interrupted response must not be interpreted as a failed transaction or trigger an automatic duplicate submission.

Delivery artifacts

Agree these outputs during scoping, then review them alongside the acceptance checks below.

  1. Journey prototype covering confirmation, pending and recovery screens
  2. Provider API mapping and sandbox integration
  3. Duplicate-request, session-expiry and interrupted-connection test results

How to evaluate delivery

  • Test duplicate submissions and interrupted connections.
  • Check that sensitive data is excluded from logs and unintended screens.
  • Obtain the provider’s acceptance before enabling live operations.