How to test retail bank overdraft limit changes

Retail bank overdraft limit change testing verifies that a requested increase or reduction is authorised, takes effect at the correct time and produces consistent transaction decisions across the bank's systems. It checks eligibility, limit values, balances, customer communications and audit records against the bank's product rules, including what happens when an account is already over the proposed limit.

Define the expected behaviour

Before designing tests, translate product and operational requirements into explicit rules. Record who can request or approve a change, which accounts qualify, permitted limits, any review or approval steps, the effective date and time, and how pending transactions are treated. Requirements may differ by account type, customer status or channel, so use the applicable product rules rather than assuming one policy for every account.

Clarify how the limit relates to the account's ledger balance, available balance, holds and pending authorisations. Define which transactions may be allowed or declined when available overdraft is exhausted, and how the system handles an existing debit balance above a newly reduced limit. A limit change must not silently alter the debt already owed. The bank's rules determine how subsequent debits, credits and customer messaging are handled.

Build scenarios around boundaries and state

Cover increases and reductions, valid and invalid requests, and changes that are pending, approved, rejected, cancelled or effective. Use boundary value testing for minimum and maximum permitted limits, values just outside those boundaries, zero where permitted, and values with unsupported precision. Check validation consistently in the user interface, application programming interface (API) and downstream services that can initiate or process a change.

Include accounts with no overdraft facility, restricted or closed accounts, existing arrears where relevant, and accounts with pending card transactions or payment instructions. Check access control and approval rules so that a user cannot approve their own change when separation of duties is required. Test the same journey in each supported channel, such as mobile banking and a contact-centre workflow, where both can change the limit.

Verify balance and transaction decisions

After approval, compare the stored limit with the customer-facing value and the value used by transaction authorisation. Submit transactions around the resulting available overdraft threshold, including a transaction that reaches the permitted boundary and one that exceeds it. Check the response, resulting balances, transaction status and any decline reason against the specified rules.

For a reduction, verify the defined treatment of an account whose current debit balance exceeds the new limit. For an increase, confirm that the extra capacity becomes usable only when the change is effective. Pending transactions can make this less straightforward: establish whether authorisation uses the limit at the time of the request, the time of settlement, or another specified point. Test reversals and later credits where these can change the account's position.

Check connected systems and evidence

Trace the change through the channel, decision or workflow service, core banking records, transaction authorisation and customer notifications. Check that each system shows the correct amount, status and effective time, and that a delayed or failed update does not leave transaction decisions using a different limit from the account record. Verify retry handling, duplicate requests and audit entries, including the actor, approval, old and new values, timestamps and outcome.

Use controlled test accounts with known balances, holds and pending transactions. Keep test data isolated from real customer records, and reset account state between scenarios. Where updates are asynchronous, verify both the initial response and the eventual state; a successful screen message alone does not prove that the limit reached the systems that enforce it.

Worked example

Assume product rules allow a limit increase from £500 to £600, effective immediately. The account has a debit balance of £420 and no holds or pending transactions. If the bank defines available overdraft as limit less the debit balance, the expected remaining capacity is £180. Confirm that the account record and transaction authorisation use £600, that a transaction within the permitted capacity follows the configured rules, and that one exceeding it receives the expected outcome.

Then test a reduction to £300 while the account remains £420 in debit. Verify that the change is recorded without changing the existing debt. Check subsequent transaction decisions and customer messaging against the documented policy for an account over its new limit. Repeat with a future effective time to confirm the old limit applies before that time and the new one applies afterwards.

Include these scenarios in regression testing when changes affect shared account, balance or authorisation services. Track each expected result to its product rule so that a policy change updates the relevant tests rather than leaving conflicting assumptions in the suite.