Private bank advisor assistant access testing verifies that staff supporting a private banking advisor can view or act on client information only within their authorised role, client relationships and permitted tasks. It checks access through the user interface and connected services, including whether restrictions remain effective for sensitive data, delegated actions and changes to an assistant's assignment.
How to test private bank advisor assistant access
Start with the approved access policy. Identify the assistant roles, the clients or households they may support, the data they may view, and the actions they may perform. Record any conditions, such as an active delegation, a particular advisory team or a supervisor's approval. If requirements leave these boundaries unclear, resolve them before writing expected results.
Authentication and authorization need separate checks. Authentication establishes who signed in. Authorization determines which client records and functions that identity can use. Role-based access control (RBAC) can assign permissions by job role, while relationship or delegation rules may further limit access to particular clients. Test the combined policy rather than assuming a role alone defines the full entitlement.
Prepare controlled accounts for an advisor, an assistant assigned to that advisor, an assistant with no assignment, an assistant assigned to a different advisor, and a user with broader authorised access. Use synthetic or appropriately masked client data. Include distinct client and household records so the test can detect access that crosses an intended boundary.
Build positive and negative checks
For each identity, test relevant combinations of client, data type and action. Actions may include viewing a profile, opening portfolio information, editing contact details, downloading a report or initiating a workflow. Include read, update, export and approval permissions where the product supports them. A permitted view does not imply permission to change or export the same information.
Check expected access and denial paths. An assigned assistant might be allowed to view a client's contact details and prepare a service request, while a payment instruction or investment mandate change may require a separate entitlement or advisor approval. An unassigned assistant should receive no access to that client's record. Verify that denial applies to direct links and service requests as well as navigation menus.
Check for indirect disclosure. Search results, dashboard totals, notifications, downloaded reports and error messages can reveal client names or financial details even when opening the underlying record is blocked. Confirm that denied requests return an appropriate response and do not expose data in the page, response payload or logs available to the user.
Verify delegation changes and connected systems
Test the lifecycle of access, including a new assignment, a changed client relationship, expired delegation and removal of an assistant from an advisory team. After a change, check both new requests and existing sessions according to the bank's policy. Verify that access is removed from connected systems such as document stores, customer relationship management platforms and reporting services where those systems receive separate entitlements.
Exercise the same permission boundary through the browser and relevant application programming interfaces (APIs). A hidden button is not an authorization control: a user may still call an endpoint directly or reuse a saved link. Check that the server enforces the entitlement for each operation. Include test runs after role or configuration changes to detect environment drift between the identity provider, application and downstream services.
Practical test example
Given an assistant assigned to Advisor A and a synthetic client belonging to Advisor A, when the assistant opens the client profile, the profile is available within the authorised scope. When the same assistant requests a synthetic client belonging only to Advisor B by direct URL or API, the request is denied and no client details are returned. When the assignment is removed, repeat both checks in a fresh session and apply the bank's specified behaviour to any existing session.
Capture the test identity, assignment state, client fixture, action, expected result and observed result. Include relevant response codes or audit events where available, without copying unnecessary personal data into test evidence. Link each check to the access requirement it verifies so a policy change can be traced to affected tests.
Frequently asked questions
How should tests handle a permission change during an active session?
Follow the bank's defined policy for existing sessions, then verify it explicitly. Depending on that policy, access may be removed immediately, on the next request or after re-authentication. Test the specified behaviour with both an existing session and a fresh login.
What access evidence should a test retain?
Retain the test identity, relevant entitlement state, action attempted, expected and observed outcomes, and any suitable audit event or response metadata. Keep evidence minimised and use synthetic or masked client records so it does not create unnecessary exposure of client information.
Should access tests use production client accounts?
Use a controlled non-production environment with synthetic or appropriately masked data wherever possible. If a production check is specifically authorised, define its scope and safeguards in advance, avoid unauthorised client access and transaction activity, and record evidence in line with the bank's controls.