What is banking parallel run testing?

Banking parallel run testing is the practice of processing equivalent banking transactions through two systems during the same period and comparing their results. It is commonly used during a core banking migration to check that the target system produces expected account, payment and ledger outcomes while the existing system remains available as a reference. The comparison needs aligned inputs, starting data and business rules to produce meaningful results.

How banking parallel run testing works

The team selects a transaction set or live transaction feed and makes equivalent inputs available to both systems. The existing platform may continue to own live processing, while the target processes a mirrored or replayed feed. Controls must prevent the target run from creating duplicate payments, customer notifications or other external effects.

The comparison covers business outputs, which can include transaction status, account balances, fees, interest, value dates, payment messages, subledger entries and general ledger totals. The precise scope depends on the migration and its risks. Technical identifiers or timestamps may differ between systems, so teams can exclude or normalise those fields where they have no business meaning. Amounts, currencies, posting status and other agreed business fields still need explicit comparison rules.

A useful comparison depends on equivalent starting conditions. Teams should align account and transaction data, product configuration, rates, calendars, cut-off times and relevant reference data. They should also control transaction order and business dates where processing depends on sequence. Differences in configuration, an incomplete input feed or environment drift can create mismatches that resemble software defects.

Reconciliation and failure analysis

Data reconciliation turns output differences into reviewable results. A reconciliation process should identify missing, duplicate and unmatched records, then compare agreed fields and totals. It should retain enough detail to trace a variance back to its input transaction, processing run and system output.

A variance can indicate a defect, a migration mapping issue, different configuration, timing or an intentional difference in system behaviour. Teams should classify each variance, investigate its cause and record the decision. An unexplained difference in a critical balance or posting field needs resolution before the run can support a migration decision. Agreed tolerances should be field-specific; a tolerance for a display timestamp would not be appropriate for a customer balance.

Parallel runs can fail to give reliable evidence when the input populations differ, the source and target begin from inconsistent data, or the run omits end-of-day and other scheduled processing. Incomplete transaction ordering can also produce temporary mismatches. Re-running a failed comparison without correcting its cause can hide a repeatable defect, so preserve the original inputs, outputs and reconciliation results.

Practical example

Suppose a bank is moving current accounts to a new core platform. A controlled feed contains a customer payment of £120, a £1.50 account fee and the associated posting instructions. Both platforms process equivalent inputs from an aligned account position.

The test compares the payment status, debit amount, fee, resulting balance and ledger postings. If the target marks the payment as complete and debits £120, but omits the fee, the reconciliation should report a field-level variance and show the corresponding ledger difference. The team can then investigate the fee rule or account configuration. The test passes only when the result matches the agreed expected behaviour, or when an authorised and documented difference has been accepted.

When to use the results

Parallel run evidence helps teams assess whether the target system can reproduce required banking outcomes before cutover. It supports decisions about migration readiness alongside other evidence, such as functional tests, migration data checks and operational rehearsal. A matching output set does not by itself prove that every workflow, exception path or operating condition has been tested.

Agree the comparison scope, run period, critical fields, exception ownership and exit criteria before execution. Verify that the feed is complete, both systems used the intended data and configuration, and every material variance has a traceable disposition. This makes the result useful for a controlled migration decision.