How to test system integration during a bank merger

Bank merger system integration testing verifies that the merging banks' applications, interfaces, data and operational processes work together correctly across agreed customer and transaction journeys. It checks that information moves between systems accurately, controls remain effective and failures are handled safely, both during migration and when systems from the two banks continue to coexist.

Define the integration scope

Start with a map of the systems and interfaces affected by the merger. This may include core banking, payment processing, customer relationship management, digital channels, fraud monitoring, identity services, finance and regulatory reporting. Record which bank owns each system, the direction and format of data flows, processing schedules, dependencies and the business owner responsible for each outcome.

Set boundaries between system integration testing (SIT), data migration testing and end-to-end testing. SIT checks interactions between connected systems. Data migration testing checks that records are transformed and loaded accurately. End-to-end testing follows a business journey across applications and operational steps. A merger programme may need all three, with shared scenarios and traceable results.

Before execution, agree data mappings, interface contracts, business rules and expected outcomes. Confirm that test environments have compatible application versions and configurations. Environment drift, unavailable third-party services or stale reference data can make a failure hard to reproduce or attribute. Use controlled test data that represents relevant account types, mandates, payment instructions and customer relationships without exposing real customer information unnecessarily.

Build scenarios around customer and control risks

Prioritise scenarios by the impact of failure. Cover common transaction paths and cases where a mismatch could affect funds, access, reporting or operational controls. Include both banks' products and any new rules introduced by consolidation.

For each scenario, specify the starting state, input, systems involved, expected state changes and evidence to collect. Useful checks include:

• Customer and account records retain correct identifiers, ownership, status and links across systems.
• A payment submitted through one bank's channel reaches the correct processing route, receives an accurate status and appears consistently in relevant account and reporting views.
• Balances, transaction history and general ledger postings reconcile after processing, including reversals and rejected transactions.
• Access rights, approval limits, mandates and screening outcomes remain correct after customer or account data is consolidated.
• Timeouts, duplicate messages, retries and downstream outages do not create duplicate transactions or leave systems in conflicting states.

Include asynchronous interfaces and scheduled jobs. Check message ordering, duplicate handling, retry behaviour, batch completion and restart recovery where those mechanisms exist. A successful response from one application does not prove that downstream systems have processed the transaction.

Run, reconcile and investigate

Execute scenarios with correlated identifiers so that a transaction can be traced through logs, messages, application records and ledger entries. Where direct database access is restricted, use approved reports, APIs or operational views as evidence. Protect sensitive data in test artefacts and limit access to them.

Compare results at each boundary, then reconcile source and destination totals at an agreed level, such as transaction counts and debit and credit amounts. Investigate mismatches by identifying the first point where actual behaviour diverges from the expected flow. Classify whether the cause is a defect, mapping issue, configuration difference, test data problem or environment failure before deciding whether to rerun.

Worked example: migrated standing order

Create a customer with an active standing order in the source bank, including its destination account, amount, frequency and next execution date. Migrate the customer and instruction, then verify the destination system holds the correct values and links the instruction to the intended account. Submit or simulate the scheduled execution through the agreed test path. Confirm that the payment is created once, follows the expected approval and screening steps, updates account and ledger records correctly, and produces the expected status or notification. Check that a rejected instruction or retry leaves no duplicate debit.

This scenario depends on an approved mapping for customer identifiers and payment instruction fields, representative reference data, and a test environment with the relevant payment and ledger integrations available. If a dependency is simulated, record which behaviour the simulation covers and test the live integration separately when it becomes available.

Set evidence-based exit criteria

Agree acceptance criteria before testing. They should cover required scenario execution, reconciliation tolerances approved by the business, unresolved defect severity, control outcomes and evidence completeness. A passed interface test does not establish that the full customer journey is correct, so report coverage by business flow and affected system as well as by interface.

Retest affected scenarios after fixes and assess whether shared components or mappings require regression testing. Keep results, defects, reconciliations and approvals linked to requirements and release decisions. This gives programme and operational owners a clear basis for deciding whether integration risks are understood before migration or cutover.