Dormant bank account testing

Dormant bank account testing verifies that an account enters, remains in and exits a dormant state according to the bank's configured rules. It checks how inactivity affects customer access, transactions, fees, interest, notifications and connected systems. The trigger period and permitted actions depend on the product, bank policy and applicable jurisdiction, so tests must use approved requirements rather than assume a universal definition.

Define the account lifecycle rules

Before designing cases, identify the account states and the events that move an account between them. A typical lifecycle may include active, inactive, dormant and reactivated states, but the names and transitions vary. Confirm whether inactivity is measured from the last customer-initiated transaction, login, contact or another event. Establish which events reset the inactivity clock and whether the rule differs by account type.

Record the expected behaviour for each state. For example, a dormant account might reject customer-initiated withdrawals while still accepting certain credits. Another product may allow some transactions after additional checks. Confirm how standing orders, direct debits, interest, fees, statements, card access and digital channels behave. Treat each as a product rule to verify, not an assumed banking convention.

Prepare controlled test data and dates

Create accounts with known balances, transaction histories, customer permissions and inactivity timestamps. Include accounts just before the dormancy threshold, at the threshold and just after it. Use the bank's configured business calendar and time zone when preparing dates. Boundary cases can expose errors in date comparisons, end-of-day processing and daylight saving transitions.

Avoid waiting for a real inactivity period to pass. Use approved test facilities such as seeded account data, a controllable application clock or a test batch date. If a batch process changes account state, confirm its schedule, rerun behaviour and recovery process. Keep test data isolated from production customers and ensure that account creation or state changes cannot trigger external payments or customer communications.

Test state changes and account behaviour

Build cases around both state transitions and actions attempted within each state. Verify that eligible activity moves an account to dormant at the correct point, while excluded events do not incorrectly reset the clock. Test the transition from dormant to active through the documented reactivation route, including any identity checks, approvals or customer-service actions that apply.

For each state, exercise relevant channels and services. Check that the core banking record, online and mobile banking, card processing, payment services, customer relationship management system and reporting feeds show consistent status where applicable. Confirm that rejected transactions return the expected reason and do not post to the ledger. Where transactions remain permitted, verify the balance, available balance, posting date and downstream records.

Check financial and operational effects as well. Verify whether interest continues to accrue, whether fees are applied or waived, and how pending payments or returned transactions are handled. Confirm that statements and notices use the correct account status and delivery rules. Review audit records for the state change, the actor or process that caused it, the effective date and any reactivation approval.

Worked example: threshold and reactivation

Suppose an approved test rule says that a particular account becomes dormant after 12 months without qualifying customer activity, with status updated by an overnight batch. This is an example rule, not a general banking standard.

Set up accounts with last qualifying activity dated one day before, on and one day after the calculated threshold. Run the batch using the correct business date. Check the resulting status and effective date for each account. Then attempt a debit and a permitted credit on a dormant account, using the expected product rules as the oracle. Confirm that any rejected debit leaves the ledger unchanged and that any accepted credit is recorded consistently across the account and reporting systems. Finally, complete the approved reactivation journey and verify that access and transaction permissions change as specified, with an auditable record of the action.

Diagnose failures and confirm evidence

A failed test may result from incorrect lifecycle logic, stale test data, environment date drift, a missed batch, or inconsistent status mapping between systems. Compare the account's source data, batch inputs and outputs, API responses, user interface status, ledger entries and audit events. Rerun only after confirming the environment and test data have returned to a known state.

Link each case to the governing rule and retain evidence of the account state before and after execution. For automated checks, assert business values such as status, effective date, transaction outcome and ledger balance rather than relying only on a screen label. This makes dormant bank account testing repeatable and helps separate application defects from data or scheduling problems.