Retail bank account package migration testing

Retail bank account package migration testing is the verification that existing accounts move from one product package to another with the intended configuration and account state intact. It checks eligibility and field mapping, as well as the application of target fees, interest, limits and service rules from the agreed effective date. The scope includes downstream updates and exception handling.

What retail bank account package migration testing covers

A package can define account features such as pricing, interest treatment, overdraft settings, transaction limits or access to services. The migration may change some of these attributes while leaving the account number, ownership and transaction history unchanged. The bank's approved migration specification determines which fields and behaviours should change.

Testing checks that each account is assigned to the correct target package and that the target configuration takes effect when expected. It also checks retained attributes, such as account status, customer links, mandates and existing restrictions, where the migration rules require them to persist. Related data migration testing checks can help verify field mapping and record integrity.

The scope should include accounts that qualify, accounts that fail eligibility rules and records that need manual review. Include relevant account states, such as dormant or restricted accounts, joint accounts, accounts with an overdraft, and accounts with pending transactions. The set of applicable cases depends on the migration rules and the bank's product terms.

Conditions and dependencies

Before testing, teams need an approved source-to-target mapping, eligibility rules, package configuration and effective-date policy. They also need a defined treatment for accrued interest, fees already charged, pending transactions and customer communications. These decisions affect expected results, so testers should not infer them from the target package configuration alone.

The test environment should contain representative account data and the services that consume package details. Depending on the architecture, those may include the core banking system, digital channels, statements, pricing services, customer relationship management systems and the general ledger. If connected systems use separate copies of package data, test that updates reach each one and that failures are visible.

Capture a pre-migration snapshot or equivalent baseline for the accounts in scope. Agree reconciliation rules for account counts, package assignments, balances and relevant financial totals. Protect customer data in test environments and preserve referential links between accounts and related records.

How to verify the migration

Check the migration at record level and through customer-facing and downstream behaviour. Confirm that source accounts map to the expected target package, ineligible records remain unchanged or enter the agreed exception process, and retained fields remain accurate. Verify that changed rules apply from the specified date, including any required treatment of transactions around that date.

Run regression checks on account activity affected by the package change. For example, verify a fee calculation, interest accrual, overdraft decision or channel feature using the target rules. Check statements and notifications where package changes should produce them. Confirm that downstream records agree with the account's package and that financial postings reconcile under the bank's defined rules. Regression testing in banking can cover unaffected account functions at risk from the change.

Failures can arise from incorrect eligibility data, incomplete mappings, stale package configuration or a partial update across connected systems. Also check duplicate processing, reruns and restart behaviour. A rerun should not apply a fee or migration update twice unless the defined process explicitly requires it. Record rejected and partially migrated accounts with enough detail for investigation and controlled remediation.

Worked example

Suppose a retail bank moves eligible current accounts from Package A to Package B on 1 May. Package B charges a £5 monthly fee, while Package A waives the fee for the accounts in this migration group. The test data includes an eligible account, an account that fails a stated eligibility rule, and an eligible account with a pending transaction.

For the eligible account, verify the target package assignment and confirm that the fee follows the approved effective-date rule. Check that the account number, customer ownership and opening balance remain as specified. For the ineligible account, confirm that it stays on Package A or enters the agreed exception queue. For the account with a pending transaction, verify that processing the transaction does not use an unintended package or fee rule. Reconcile the migrated population against the baseline and review any rejected records before sign-off.

Evidence should link each migration rule to its test result and reconciliation outcome. A release decision should account for unresolved exceptions, financial differences and any downstream update failures.