How to test an enhanced due diligence workflow

Enhanced due diligence workflow testing checks that a banking system identifies cases requiring enhanced review, gathers and assesses the required information, routes decisions to authorised staff, and records an accurate, traceable outcome. It verifies the workflow against the bank's approved policies and configuration, including decision rules, integrations, permissions and exception handling.

Define the workflow and its expected outcomes

Enhanced due diligence (EDD) is additional scrutiny applied to a customer or relationship under a bank's policies. The circumstances that trigger it and the checks performed depend on those policies and the applicable requirements. Testing should therefore start with approved rules and process documentation, rather than assumptions about a universal EDD process.

Map the workflow from the triggering event to its final status. A trigger might be a customer risk rating, a screening result or a periodic review. Identify the systems that supply customer and ownership data, perform screening, store documents, manage cases and record decisions. For each step, specify the expected status, permitted role, data change and audit event.

Agree measurable acceptance criteria with compliance and operations teams. For example, a high-risk trigger may need to open an EDD case, prevent onboarding from completing until an authorised decision is recorded, and retain the decision and its rationale. Confirm whether the workflow allows conditional progression, requests further information or sends a case back for correction.

Prepare controlled test data and environments

Create test records for the relevant branches: a case that triggers EDD, one that does not, an incomplete ownership record, a potential screening match requiring review, and a case where evidence is missing or expired. Include different customer types if their workflows vary, such as individuals and corporate customers with multiple beneficial owners.

Use synthetic or appropriately anonymised data, with stable identifiers shared across integrated systems. Check that test records cannot trigger real customer communications, production screening actions or regulatory submissions. Record the environment configuration, rule versions and service stubs used. Differences in screening lists, thresholds, permissions or reference data can otherwise make results inconsistent between environments.

Where a third-party screening service is involved, agree how to represent match, no-match, timeout and error responses. A stub gives repeatable results for workflow tests; a controlled integration test can then check the real interface and data mapping. Both approaches have limits: a stub cannot prove the provider behaves as expected, while a live dependency can make execution less predictable.

Test the workflow end to end

Run cases through the same application steps and interfaces used by staff or connected systems. Verify the trigger, case creation, data passed between systems, task assignment, decision controls and final status. Include role checks: an unauthorised user should not approve a restricted decision, and a user should not be able to bypass a required review through another screen or interface.

Cover positive, negative and boundary conditions. Check that a genuine trigger enters the EDD path, a non-trigger does not, and missing or conflicting data produces the documented response. Test duplicate events, repeated submissions, timeouts, retries and cases returned for more information. Confirm that a retry does not create duplicate cases or overwrite an existing decision. If policy rules use thresholds, test values immediately below, at and above each boundary.

Assert both visible outcomes and persisted records. A case marked complete in the user interface should agree with its status in the case system and any downstream customer record. Check timestamps, actor identity, decision rationale and changes to key fields in the audit history. Verify that failed or incomplete work remains visible to the correct queue and cannot be mistaken for approval.

Worked example: corporate customer ownership review

Suppose an approved rule sends a corporate customer to EDD when an ownership record meets the bank's high-risk criteria. Prepare a synthetic company with two beneficial owners and a screening response that requires manual review for one owner.

Submit the customer record and verify that the system creates one EDD case, links both owners, flags the relevant screening result and assigns the case to the permitted review queue. Attempt approval with a role that lacks authority; the action should be rejected and recorded. Then approve with an authorised role, providing the required rationale. Confirm that the case closes, the customer status changes as specified, and the audit history records the reviewer and decision. Repeat the submission to check duplicate handling, then test a screening timeout to confirm the case remains pending or follows the documented exception route.

Evaluate failures and maintain coverage

Treat incorrect routing, missing evidence, unauthorised approval, inconsistent statuses and incomplete audit records as workflow defects. Triage integration failures separately from rule or user-interface failures, using logs and correlation identifiers to locate where the state diverged. Retest the affected path and run regression cases for shared rules, role controls and downstream status updates.

Keep test cases traceable to policy rules and process steps. Revisit them when those rules, screening integrations, data models or staff permissions change. Risk-based selection can focus frequent regression on routes with greater customer or control impact, while periodic end-to-end runs check that connected systems still agree. Link this work to [Banking test data management] and [End-to-end testing in banking] where those topics need separate treatment.