Bank account overdraft testing verifies that a banking system applies an account's overdraft rules correctly when transactions would reduce its balance below zero. It checks eligibility, authorised limits, transaction decisions, balance updates and related charges or interest against the product requirements, including cases at and beyond the permitted limit.
What bank account overdraft testing covers
An overdraft facility allows an eligible account to have a negative balance up to a configured amount. The facility may be arranged in advance, or the product may define how an unarranged overdraft is handled. Rules vary by account, jurisdiction and bank, so expected results must come from approved product requirements and configuration rather than assumed industry behaviour.
Tests typically check whether an account is eligible, whether its facility is active, and how a debit affects the balance and remaining overdraft headroom. They also check what happens when a transaction exceeds the limit: for example, whether it is declined, partially processed or handled through another specified rule. The system may also need to calculate charges or interest, issue a notification, and record the event for customer service or audit purposes.
The decision can depend on more than the displayed balance. Available balance may account for pending card authorisations, holds, fees or other transactions, while the ledger balance reflects posted entries. Tests should establish which balance and transaction state the overdraft rule uses. They should also cover transaction ordering, because a series of individually valid debits can exceed a limit when processed together.
How to test the overdraft boundary
Use boundary value testing around zero and the configured limit. Prepare controlled accounts with known balances, facility limits and transaction states. Check the exact boundary, then test amounts just inside and just outside it. Confirm the expected result at each stage in the user interface or API, the account ledger and any downstream records in scope.
For example, assume a test account has a posted balance of £80, an active arranged overdraft limit of £100, and no holds or pending transactions. A debit of £150 should leave a balance of -£70 if the product permits it. The remaining overdraft headroom should be £30. A subsequent debit of £40 would take the balance to -£110, so the test should assert the configured outcome for exceeding the limit, such as a decline. It should also verify that a declined debit does not create a posted ledger entry. These expected results depend on the specified product rules.
A useful test case records the starting balance and facility state, submits the transaction, and checks the transaction status, resulting balances and relevant records. Where the transaction is accepted, verify that it is posted once and that the available balance reflects the facility correctly. Where it is rejected, check that neither the ledger nor related balances change unexpectedly.
Dependencies and failure modes
Reliable results depend on controlled test data and a known environment configuration. A refreshed test environment may have different account settings, fee tables or transaction-processing rules. Confirm these before execution, and avoid using live customer accounts for tests that change balances or generate charges.
Include scenarios for an inactive or expired facility, a limit change, a credit that restores headroom, and a reversal of a debit. Test concurrent debits where the system can receive transactions at the same time. A race condition may allow both transactions to pass a limit check based on the same earlier balance. Retry handling also matters: repeating a request should not create an unintended duplicate debit.
Common defects include checking the wrong balance, applying a stale limit, accepting an over-limit transaction, changing the balance after a declined transaction, or calculating charges from an incorrect balance or period. Separate overdraft eligibility and transaction-decision checks from detailed interest calculations where that makes failures easier to diagnose. For interest-specific rules, see Overdraft interest calculation testing.
Frequently asked questions
How does overdraft testing differ from credit card limit testing?
Overdraft testing focuses on a deposit account's balance, facility rules and transaction processing when the balance becomes negative. Credit card limit testing focuses on the card account's credit exposure and authorisation rules; each product needs its own specified balance and limit calculations.
Can overdraft tests use production customer accounts?
Use controlled test accounts in an appropriate non-production environment wherever possible. Tests can alter balances, create charges or trigger customer communications, so production execution requires explicit operational controls and authorisation.
What should be checked when an overdraft limit changes?
Check the new limit, its effective time and the resulting available headroom. Verify behaviour for transactions submitted before and after the change, including any pending transactions, against the product's rules for applying limit updates.