How to test corporate bank accounts across multiple entities

Corporate bank multi-entity account testing checks that accounts, transactions, users and reports are handled according to the legal entity that owns each account and the permissions assigned to each user. It validates entity-level isolation, explicitly authorised cross-entity access and consistency across the corporate banking channels in scope, such as a portal, application programming interface (API) and statement service.

Define the entity and account model

Start with the bank's configured relationship model. A corporate group may contain a parent company, subsidiaries and branches, with accounts assigned to particular legal entities. The configuration determines whether an entity can view or operate accounts held by another entity, and whether access is inherited through the hierarchy.

Record the expected ownership and access rules before writing tests. Include user roles, account entitlements, payment approval limits, reporting scope and any permitted group-level access. Confirm how the system represents entity identifiers across the portal, APIs, payment processing and reporting. The same label may appear in several channels while referring to different internal identifiers.

Prepare controlled test data with at least two entities and accounts that can be distinguished reliably. Include a user with access to one entity, a user with access to both entities, and a user with no access to either. Use synthetic data or approved masked data. Confirm that account ownership, user entitlements and transaction data are consistent across dependent services before execution. Environment drift in roles or account mappings can make an access test inconclusive.

Test entity-scoped access and workflows

Build tests around allowed and denied actions. Check account search, balances, statements, payment creation, approval and reporting wherever those functions are in scope. Verify access through the interface and, where available, the API. A hidden account in a selector is useful evidence, but it does not prove that a direct request for the account is also rejected.

Cover these conditions:

• A user with access to Entity A can view and operate its permitted accounts.
• The same user cannot retrieve Entity B's account through search, a direct account reference, a report or an API request.
• A group-level user sees both entities only when that access is configured.
• Payment creation and approval follow the account's entity-specific mandate and approval rules.
• Statements, exports and transaction searches contain records within the user's authorised scope.
• An account with a similar name in another entity remains distinguishable by its ownership and account identifier.

For each attempt, assert the result and the side effects. A denied payment should leave balances and payment state unchanged. Check that the denial is recorded where the audit requirements call for it, and that the record identifies the acting user, entity and attempted action without exposing unnecessary account data.

Multi-entity testing overlaps with multi-tenant testing, but the boundary depends on the system model. A tenant commonly represents a separate customer or organisational partition. A corporate group may have several legal entities inside one customer relationship, with deliberate group-level access between them. Test the configured boundary instead of assuming that every entity must be isolated from every other entity.

Worked example: test a payment boundary

Assume North Ltd and South Ltd each hold a current account. Priya can make payments from North Ltd's account. Her role has no access to South Ltd. A group treasury user can access both accounts under an approved group mandate.

1. Sign in as Priya and confirm that North Ltd's account is available for payment creation.
2. Submit a permitted test payment from North Ltd's account and check the payment record, approval state and resulting balance behaviour against the configured workflow.
3. Request South Ltd's account directly by its test identifier through the portal and API. Assert that account data and payment actions are denied.
4. Search the payment list and download the available report. Assert that South Ltd's account and transactions are absent.
5. Repeat the visibility checks as the group treasury user. Assert that both accounts appear, and verify that payment authority still follows the group user's configured mandate.

Run the checks against stable test fixtures and reset mutable balances and payment states between runs. If a test fails, inspect the entity mapping, effective entitlements and downstream service response before classifying it as an application defect. Keep evidence such as test data identifiers, user role, request or screen, expected result and observed result so the failure can be reproduced.