What is core banking replacement testing?

Core banking replacement testing verifies that a bank can move from its existing core platform to a replacement and continue processing customer accounts and banking operations correctly. It covers migrated data, business rules, transaction processing, connected systems and the cutover itself, with evidence that balances and financial records remain accurate across the transition.

What does core banking replacement testing cover?

The scope depends on which products, functions and interfaces are moving. Testing commonly spans the conversion of customer, account, balance, transaction-history and reference data, along with the replacement platform's configuration and business rules.

Teams check that key workflows still behave as required. These may include account servicing, deposits and withdrawals, interest and fee calculations, payment processing, statements and end-of-day processing. Regression testing checks that established behaviour remains correct after the change. Integration testing checks exchanges with channels and connected systems such as payment services, customer relationship management platforms and the general ledger (GL).

The work also covers migration controls and operational readiness. For example, teams verify record counts, field mappings, data relationships and financial totals. They test how batches recover from interruption, how errors are reported and how the bank would restore service or data if cutover fails. Performance and volume tests can reveal whether the replacement can handle expected processing loads.

What needs to be in place before testing?

Teams need an agreed inventory of products, workflows, interfaces and data being moved. Migration mappings should specify how source fields and values translate to the target, including how unsupported or invalid records are handled. Product configuration, transaction rules, date conventions and rounding behaviour need defined expected results.

Test data must represent relevant account and customer states while following the bank's data controls. Environments need the required versions of the core and connected systems, plus representative interface behaviour. Differences between test and production configuration can hide defects, so environment settings and reference data should be controlled and recorded.

Reconciliation rules also need agreement before execution. The bank should define which totals and records must match, how legitimate transformation differences are treated, who reviews exceptions and what evidence is required for sign-off. Unexplained balance differences, missing transactions, broken account relationships or inconsistent status values are potential release blockers. A test pass alone does not make a migration discrepancy acceptable.

How is a replacement tested in practice?

Testing combines migration checks with functional, regression and end-to-end scenarios. A team may first validate a converted data set, then run account and payment workflows against it. Where the migration approach permits, a parallel run can compare outputs from the existing and replacement platforms for the same inputs. Differences need analysis because timing, configuration or calculation rules may explain some variations, while others may indicate data or processing defects.

A practical test could migrate two current accounts with ledger balances of £500 and £100. After confirming the converted account records and opening balances, the tester initiates a £75 transfer between them. Expected results include balances of £425 and £175, a recorded transfer with the correct accounts and value date, corresponding postings in the GL, and consistent transaction status in the relevant customer channel. The tester then checks that the transaction appears correctly in account history and that reconciliation totals reflect the movement. The scenario should also cover a rejected transfer, such as one that exceeds the permitted balance, to confirm that no debit or credit is posted when the payment fails.

Results should be traceable to requirements and migration rules. Defects need enough detail to reproduce the issue, including input data, processing date, account state and affected interface. Teams should retest fixes and run relevant regression scenarios, since a change to a mapping or posting rule can affect other products or downstream systems.

How do teams assess readiness?

Readiness depends on agreed evidence, not a single test pass percentage. Reviewers examine unresolved defects according to their customer, financial and operational impact; reconciliation exceptions; completion of critical workflows; and results from cutover and recovery rehearsals. They should also confirm that operational teams can monitor processing, investigate exceptions and support customers after migration.

A release decision should follow the bank's defined acceptance criteria and risk controls. If a critical workflow has no reliable expected result, a material financial difference remains unexplained, or the rollback approach has not been exercised, the evidence is incomplete and the migration risk remains open.