Core banking configuration testing verifies that settings and business rules in a core banking system produce the required account, transaction and ledger behaviour. It checks configured values such as product eligibility, fees, interest rates, limits and posting rules against approved requirements, including how they behave at boundaries and across related banking processes.
What configuration testing covers
A core banking platform uses configuration to control how products and processes behave. A change might alter a savings account fee waiver, an overdraft limit, an interest tier or the accounting treatment for a transaction. Configuration can apply by product, customer segment, currency, channel or effective date, so the test scope should identify which accounts and transactions the rule affects.
Testing covers the configured rule and its effects. For a fee change, that can include eligibility, calculation, posting to the account, the corresponding general ledger entry and the customer statement. For an interest change, it can include the rate applied, accrual, posting date and resulting balance. The expected results should come from approved business rules and accounting requirements, including any required rounding or date conventions.
Configuration testing is a form of functional testing. It often includes regression testing because a parameter change can affect existing products or shared processing rules. It can also involve integration testing when downstream systems receive the resulting transaction or ledger data.
How to test a configuration change
Start with the approved change specification and record the affected configuration items, products, processes and effective dates. Confirm the test environment has the intended configuration version, relevant dependencies and suitable test data. Environment drift, stale product settings or incomplete reference data can make results unreliable.
Design tests for normal behaviour, boundaries and exceptions. Use accounts that meet and fail eligibility rules, and cover transaction states that may affect the rule, such as reversed or pending transactions. Where a setting changes for a future date, verify behaviour on both sides of the effective date. Check persisted account data and ledger entries as well as any customer-facing output.
A useful test record links each requirement to its test data, configuration version, expected result and execution evidence. This makes it easier to review the change and identify which regression tests need to run when the configuration changes again.
Practical example: monthly fee waiver
Assume a current-account product has a monthly fee of £5, waived when the account has at least five eligible debit transactions in the statement period. The eligible transaction definition and statement-period dates are specified in the approved rule.
Create test accounts with four and five eligible transactions. After the period closes, verify that the four-transaction account receives the £5 fee and that the five-transaction account does not. Check the account balance, fee transaction, general ledger posting and statement output. Add cases for a reversed debit and a transaction outside the period to confirm that they do not count if the rule excludes them. Run an existing fee or account-maintenance regression test to check that the change has not altered unrelated product behaviour.
The exact expected ledger accounts and transaction descriptions depend on the bank's accounting design. Tests should use the approved mapping rather than assume a particular chart of accounts.
Common failure modes and trade-offs
A test can pass against the wrong configuration version, miss a boundary condition or check only the front-end display while a fee or posting is incorrect in the core ledger. Shared settings can also affect products outside the change request. Verify the active configuration and use assertions at each relevant processing layer.
A focused test set gives faster feedback, while broader regression coverage can reveal side effects across products and interfaces. Select regression tests according to the scope and risk of the change, and include end-to-end checks when the configuration affects a customer journey or downstream system.
Frequently asked questions
How does configuration testing differ from testing custom code?
Configuration testing checks behaviour controlled by settings, parameters and rules in the core banking platform. Custom code testing checks behaviour implemented through newly written or changed software logic. A release can require both when configuration depends on a code change.
Can core banking configuration tests be automated?
Yes. Stable, repeatable checks can automate account setup, transaction submission and assertions on balances, fees or ledger postings. Automation still depends on controlled test data, a known configuration version and review of expected results when business rules change.
Who should approve a core banking configuration change?
Approval should follow the bank's change-control process and include the accountable business or product owner and relevant technical, operations or finance reviewers. The required approvers depend on the change's scope, accounting impact and internal controls.
How can teams test a configuration that shares settings across products?
Identify every product and process that inherits or references the shared setting, then test representative affected and unaffected cases. If dependencies cannot be isolated in the test environment, document them and include the relevant cross-product regression checks.