Retail bank deceased customer workflow testing checks that a bank processes a death notification accurately, applies the required controls to the customer’s products and access, and records each decision through to the appropriate outcome. The expected handling depends on the bank’s approved procedures and applicable rules, so tests must verify those requirements instead of assuming every account is frozen or closed in the same way.
Define the workflow and its decision points
Map the process from notification to resolution across the systems involved. A typical journey may include customer relationship management (CRM), document handling, core banking, card processing, digital banking, payments, and correspondence services. Confirm which system owns each status and which events trigger updates in connected systems.
Turn requirements into testable rules. These might cover who can register a notification, what information or evidence is required, when a case needs review, and which actions apply to each product or ownership type. Include sole and joint accounts, savings products, cards, lending products, and any linked mandates where they are in scope. Record exceptions and escalation paths.
Use a state model to describe valid transitions, such as notification received to evidence under review, then to accepted, declined or resolved. Test that users cannot skip required reviews or perform restricted actions from an invalid state. State transition testing in banking can help structure this coverage.
Prepare controlled test data
Create synthetic customer and account records with realistic relationships and varied product states. Include sole and joint ownership, active and dormant accounts, pending payments, scheduled transactions, linked cards, and different contact or mandate arrangements. Keep identifiers consistent across systems so that the same test customer can be traced through the workflow.
Set up data for both valid and invalid notifications. Examples include missing information, unreadable documents, mismatched customer details, and a repeated notification for the same person. Define the expected result for each case before execution. Restrict access to test data and prevent test notifications from reaching real customers or external recipients. Banking test data management is especially important when workflows handle sensitive personal information.
Exercise the end-to-end journey
Run a complete case from notification entry through the final system updates and customer or representative communications. Verify the case status, account controls, payment handling, card or digital access changes, correspondence, and audit records against the approved rules. Check each system directly where possible, including through API assertions, database checks approved for testing, or downstream event records.
Include failure and recovery paths. For example, make a connected service unavailable during an update, then restore it and verify that the workflow retries safely. Check for duplicate case creation or repeated account actions after a timeout or message redelivery. Confirm that a failed update is visible to an authorised user and can be resolved without losing the case history.
Test permissions as well as business rules. A user who can register a notification may not be authorised to approve evidence or change account controls. Verify that restricted actions are denied, recorded, and unavailable through alternate screens or interfaces. Check that sensitive details are only shown to roles permitted by the bank’s requirements.
Worked example: a joint account
Create a synthetic customer who holds a joint current account and a separate sole savings account. Submit a valid notification, then follow the configured review and approval steps. Verify that the workflow applies the specified treatment to each account according to its ownership and product rules, updates connected systems, and records who performed each action.
Repeat the case with incomplete evidence and with a duplicate notification. The incomplete case should follow its defined review or information-request path without triggering unauthorised downstream actions. The duplicate should follow the bank’s specified duplicate-handling rule without creating unintended repeated changes. Compare the recorded case history and account states with the acceptance criteria.
Verify outcomes and regression coverage
Reconcile the final case status with the relevant account and service states. Check that events arrive in the required order, failed updates remain visible, and retries do not cause duplicate effects. Confirm that timestamps, user actions, decision reasons, and communications are recorded wherever the requirements require them.
Keep regression tests around high-risk rules and integrations, then rerun them when workflow configuration, core banking interfaces, document handling, or access controls change. End-to-end testing in banking is useful for the full journey; focused component and integration tests can help isolate failures when an assertion fails.
Frequently asked questions
How should date-of-death balances be tested?
Test the balance calculation against the bank’s approved date, time, transaction and value-date rules. Use records with transactions around the relevant date, and reconcile the expected result to the applicable ledger or balance view.
What should happen if a notification arrives while a payment is pending?
The payment outcome should follow the bank’s documented rules for that account and payment state. Verify that the workflow records the decision, keeps payment and account statuses consistent, and handles any later response or reversal without duplicating an action.
How should conflicting instructions from representatives be tested?
Use scenarios with representatives whose authority differs or is unclear under the bank’s rules. Verify that the workflow checks the required authority, routes unresolved conflicts for review, and prevents disclosure or account changes until the required decision is recorded.