How to test a private banking portal

Private banking portal testing checks that a bank's web portal presents client and portfolio information accurately, enforces each user's access rights, and supports the journeys the service offers. It covers functional behaviour, integrations, security, accessibility and browser compatibility. Testing should reflect the bank's client, account and mandate model, since a portal may expose sensitive information across several relationships or legal entities.

Plan private banking portal testing around client journeys

Start with requirements, permissions and the portal's supported services. Identify the user types, such as clients, joint account holders and advisers, and define what each can view or do. Confirm how the portal represents groups, trusts, delegated access and investment mandates where those are in scope. Record which systems supply balances, holdings, valuations, documents and messages.

Turn that information into end-to-end scenarios. For example, a client may sign in, review a portfolio, open a statement, send a secure message and sign out. Check that each step uses the right client context and that information remains consistent when the user moves between pages. Include failed and interrupted journeys, such as an expired session during a document download or a failed transfer submission.

Use traceable test cases for high-impact actions and data. For an investment instruction, verify the displayed holding and available amount, the instruction details, any required confirmation, and the resulting status. Where the portal submits instructions to another system, check the response and resulting record there as well as in the portal.

Verify data and integrations

Create controlled test data with known account balances, portfolio positions, currencies, fees and statement dates. Compare portal displays with the authoritative source or an agreed test fixture. Check rounding, currency labels, valuation timestamps, pending transactions and empty or unavailable data states. A page can render correctly while showing stale or incorrectly mapped information.

Test integration failures deliberately. Simulate a delayed portfolio feed, unavailable document service or rejected instruction, where the test environment supports those conditions. Confirm the portal communicates the state accurately, avoids presenting an unconfirmed action as complete, and recovers without creating duplicate instructions when a user retries.

Protect test data throughout execution. Use synthetic or appropriately masked records, restrict access to test accounts, and prevent screenshots or logs from exposing sensitive values. Avoid copying production client information into lower environments unless the bank's approved controls explicitly permit it.

Test access controls and security

Validate authorisation on the server side as well as in the interface. A user who lacks permission should not retrieve another client's account or document by changing a URL, request parameter or API call. Check access across client relationships, account types and delegated roles. Test that signing out, session expiry and authentication challenges behave as specified, including when a browser tab remains open.

Include security testing for input handling, error messages, transport security and sensitive-data exposure in pages, downloads, browser storage and logs. Use the bank's approved security test approach and environment. Portal checks support security assurance; they do not replace specialist security assessment where one is required.

Check accessibility and browser behaviour

Test keyboard navigation, visible focus, form labels, error messages, contrast and page structure with assistive technology. Confirm that security prompts and time-sensitive steps remain operable for users who do not use a mouse. Automated accessibility checks can find some markup issues, while manual checks are needed for interaction and screen-reader behaviour.

Run the main journeys on the browsers and devices the bank supports. Check responsive layouts, document viewing and download behaviour, and browser back or refresh actions around sensitive workflows. Use stable selectors in automated tests and assert meaningful page content or service responses rather than relying only on timing or screenshots.

Use a worked test case

Scenario: A client with access to one investment account attempts to open a statement belonging to another client.

Precondition: The test user can access account A. Account B belongs to a separate client and has a known statement identifier.

Action: Sign in as the test user, then request account B's statement through the portal route or the relevant service request.

Expected result: Access is denied, no statement content or sensitive metadata is returned, and the event is recorded according to the bank's audit requirements. Repeat through the interface and the underlying request path, because hiding a link alone does not prove access is restricted.

Keep execution evidence tied to requirements and defects, including the user role, test data reference, environment and observed result. Before release, review unresolved failures against the impact of affected client journeys and confirm that fixes have passed relevant regression tests.