How to test integration in a cooperative bank branch system

Cooperative bank branch system integration testing checks whether branch applications exchange accurate, complete and timely data with the core banking platform and other connected services. It follows transactions across system boundaries, including member and account lookup, teller processing, posting, receipts and reconciliation. The aim is to verify the interfaces and shared business outcomes that branch staff rely on during everyday operations.

Define the integration scope

Map the systems involved in each branch workflow. Depending on the bank's architecture, these may include teller or branch desktop software, the core banking system, member records, identity and access services, payment or cheque processing, cash management, and the general ledger. Include only systems that participate in the selected workflows.

For a cooperative bank, check whether the branch flow also handles membership status, member share accounts or eligibility rules. These depend on the bank's products and configuration. Confirm the expected behaviour with approved requirements, interface contracts, posting rules and operational procedures before writing tests.

System integration testing (SIT) focuses on data and behaviour across connected systems. It can expose interface mapping, sequencing and error-handling defects. End-to-end testing may extend further into a complete customer or member journey, while user acceptance testing checks whether the workflow meets branch and business needs.

Prepare the test conditions

Use an environment with compatible versions and representative interface configuration. Record dependencies such as message queues, scheduled jobs, branch calendars, user roles, account settings and external service endpoints. Differences between environments can change routing, permissions or posting behaviour, so compare relevant configuration before execution.

Prepare controlled test data for members, accounts, branches, teller users and transaction limits. Use synthetic or appropriately anonymised data, and preserve referential links between records. Agree which transactions may be run, how test records will be identified, and how the environment will be reset. Confirm that test activity cannot reach live payment networks or production accounts.

For each scenario, document the starting state, action, expected messages, resulting records and reconciliation checks. Include normal processing and failure paths, such as a rejected request, a delayed response, a timeout after submission, a duplicate message and a reversal. Specify the expected retry behaviour and whether the user should see a pending, failed or completed status.

Trace a branch transaction across systems

Follow each transaction using a stable reference, such as a transaction identifier or message correlation identifier. Check the source request, interface payload, receiving system response, core transaction, account balance, branch cash position and any downstream accounting entry. Where processing is asynchronous, define an acceptable processing condition and verify eventual completion or a visible exception.

Validate field mapping and business meaning, including member and account identifiers, amount, currency, transaction date, value date, branch, teller and transaction status. Check that rejected or incomplete messages produce an actionable error and do not leave partial financial records. Database inspection can support diagnosis, though it should not replace checks through the relevant application or interface.

Worked example: cash deposit at a branch

Set up an active member account, an authorised teller, a branch cash position and the approved accounting configuration. Record the opening account and cash balances. Submit a cash deposit through the teller application and capture the transaction reference.

Verify that the core system accepts the intended member and account, applies the correct amount and dates, and returns a successful status. Check that the teller application displays the same result and produces the expected receipt. Confirm that the account balance and branch cash position change according to the defined rules. Check the journal entries against the bank's approved posting mapping; the exact accounts and posting sequence are configuration-dependent.

Repeat with an invalid account and confirm that no deposit is posted. Simulate a timeout after the request is sent, then retry using the supported recovery path. Verify that the transaction is posted once, or that staff receive a clear exception requiring resolution. Reconcile the teller record, core transaction and accounting output using the transaction reference.

Investigate failures and judge results

Classify failures by boundary: branch application, interface transport, validation, core processing or downstream posting. Preserve timestamps, references, masked payloads, response codes and relevant logs so teams can identify where data changed or processing stopped. Check for stale test data, clock differences, duplicate delivery and configuration drift before attributing a defect to application logic.

A scenario passes when the connected systems show the expected business outcome, financial records reconcile, and any failure path leaves a controlled state with evidence for investigation. Record defects against the affected interface and workflow, then rerun the failed scenario and relevant neighbouring flows after a fix. Retain traceable results for the tested configuration and release.