How to test a corporate banking portal

Corporate banking portal testing checks that business customers can access the right accounts and services, create and approve transactions correctly, and see accurate outcomes across connected banking systems. It covers user journeys, permissions, payment rules, security controls and integrations, with evidence that each transaction reaches the expected state without unauthorised access or unintended processing.

Plan corporate banking portal testing around risk

Start with the portal’s users, services and connected systems. Map roles such as payment preparer, approver and read-only user to their permitted actions. Identify account structures, legal entities, currencies, payment types, approval mandates and any limits that affect processing. Use these rules to derive scenarios and link them to requirements or business controls.

Prioritise workflows where errors could cause financial loss, expose confidential data or delay business operations. A payment journey may depend on the portal, identity service, payment hub, core banking system and notification service. Agree which components are available in the test environment, which are simulated, and where each expected result can be verified.

Prepare controlled test data for different users, accounts, currencies, mandates and transaction states. Check that data relationships remain valid across systems. Keep test credentials and payment details out of logs and screenshots where they could reveal sensitive information. Avoid sending test payments to real beneficiaries unless an approved, controlled process explicitly requires it.

Test access, payments and account information

Verify authentication and authorisation separately. Check sign-in, session expiry and re-authentication, then confirm what each user can view and do. Test direct access to restricted pages or actions as well as the visible navigation: hiding an approval button does not prove that the underlying action is protected. Include users with access to several entities and confirm that switching entities does not expose another entity’s accounts or transactions.

For payment workflows, cover creation, validation, submission, approval, rejection, amendment, cancellation and status tracking where these actions are supported. Test approval thresholds, signing mandates, maker-checker separation, cut-off rules and limit boundaries against the bank’s stated requirements. Check invalid account details, unsupported currencies, insufficient permissions and duplicate submissions. Confirm that errors explain the next safe action and that a failed attempt has no unintended financial effect.

Check account balances, transaction history, statements and payment statuses against an authoritative source, such as a test ledger or payment-service record. Verify amounts, currency, value date, fees and transaction references. For bulk payments, include valid and invalid records in the same file and confirm how partial acceptance or rejection is reported. Test that uploaded files receive appropriate validation and that resubmission cannot create unintended duplicate payments.

Check integrations, security and recovery

Trace representative journeys across connected systems. A portal may show a payment as submitted while downstream processing remains pending, rejected or completed. Verify that status changes reach the portal accurately and in the expected order. Check API or file validation, timeouts, retries and reconciliation behaviour. When a dependency is unavailable, confirm that the portal gives a clear status and does not invite a retry that could create a second transaction.

Security testing should cover access control, session handling, sensitive data exposure and input validation. Check that one corporate customer cannot retrieve another customer’s information by changing an identifier or replaying a request. Confirm that audit records capture relevant actions, such as payment creation and approval, with enough information to support investigation. Conduct intrusive security tests only in authorised environments with agreed safeguards.

Include browser and device coverage for the combinations supported by the organisation. Check keyboard operation, readable validation messages and layouts used for lengthy account names or payment references. For critical workflows, run regression tests after changes to portal code, payment rules, identity configuration or integrated services. Monitor test stability and investigate failures caused by environment drift, stale data or timing before treating them as product defects.

Practical example: two-person payment approval

Set up a test company with one payment preparer and one approver, an account with sufficient funds, and a payment below the applicable approval limit. The preparer creates and submits the payment. Verify that it enters the expected pending state, appears in the approver’s queue and cannot be approved by the preparer. The approver signs in, reviews the details and approves it.

Check the resulting status in the portal and the downstream test record. Confirm the amount, beneficiary, currency and reference match the submitted instruction, and that the audit trail records both users’ actions. Then repeat with the preparer attempting to approve the payment, an approver outside the mandate, and a repeated submission. Each attempt should follow the configured rule, leave no unauthorised payment processed and produce an explainable result.