What is customer due diligence workflow testing?

Customer due diligence workflow testing checks that a financial service's customer due diligence process applies its configured rules, moves cases through the correct states and records the evidence needed for review. It covers the journey from data collection and identity checks through screening, risk assessment, approval or escalation, and any required follow-up. Tests should reflect the institution's policies and applicable obligations, which vary by jurisdiction and customer type.

What the workflow includes

Customer due diligence (CDD) is the process of gathering and assessing information about a customer to understand risk and support a decision about the relationship. Know your customer (KYC) checks, such as identity verification, form part of this process. A workflow may also include sanctions or politically exposed person screening, beneficial ownership checks, customer risk scoring, manual review and periodic review scheduling.

Testing follows the case across the systems and teams involved. A digital application may pass information to an identity service, a screening provider, a case management platform and a core banking system. The checks need to cover the data passed between these components as well as the decisions each one makes.

What to test

Start with the approved process rules and map each case state, decision and hand-off. Check that required information is captured, validation errors are clear, and incomplete or inconsistent data cannot bypass required checks. Verify that risk factors produce the expected outcome under the configured rules, including boundary values and combinations of factors.

Exercise normal and exceptional paths. These may include a clear screening result, a possible match sent for review, an identity check that cannot be completed, missing ownership information, an expired document, a customer who does not respond, or an authorised reviewer rejecting a case. Confirm the resulting state, permitted next actions, notifications and audit history. Test role permissions and separation of duties where different people must review and approve a case.

Where a workflow depends on external services, verify responses, timeouts, retries and unavailable-service handling. A delayed screening response, for example, should not allow an account to become active if the configured process requires screening clearance first. Check that retries do not create duplicate cases or lose a review decision.

A practical example

Suppose the approved process requires a possible screening match to be reviewed before onboarding can continue. Create controlled test data that produces that outcome in the test environment. Submit the customer case and verify that it enters the review queue, the reviewer can see the relevant match details, and the case remains blocked from activation while the decision is pending.

Then test both authorised outcomes. If the reviewer clears the match, confirm that the case proceeds to the next permitted step and records who made the decision. If the reviewer confirms a match, confirm that the configured restriction or rejection path runs and that ordinary onboarding actions remain unavailable. Check the persisted case record and downstream status as well as the user interface, since a correct screen alone does not prove that connected systems received the right state.

Test data, environments and evidence

Use synthetic or appropriately protected test data. It should represent the characteristics needed to exercise rules, such as customer type, ownership structure, document status and screening outcome. Avoid copying production personal data into lower environments without approved controls. Test data must also remain consistent across connected services; mismatched identifiers can make a workflow appear to fail for the wrong reason.

Environment drift can change outcomes. Record relevant rule versions, service stubs or test-provider responses, and environment configuration with the test run. If a screening integration is simulated, verify separately that the application handles the simulated responses as expected; this does not prove the live provider integration works.

Retain traceable evidence linking the requirement or policy rule to the scenario, inputs, expected result and observed result. Include the case state and decision history where available. For automated checks, assert persisted status and downstream effects through suitable interfaces, such as an API or test database view, as well as visible behaviour when that matters to users.

How it differs from general workflow testing

General workflow testing checks process sequencing and hand-offs. Customer due diligence workflow testing applies that discipline to customer risk controls, screening decisions, evidence and review requirements. Compliance testing may cover a wider set of controls, while CDD workflow testing focuses on the customer due diligence journey. It supports compliance assurance, though passing software tests does not establish that a process meets every legal or regulatory obligation.