How to test an AML case management workflow

AML case management workflow testing checks that an anti-money laundering (AML) case moves through its defined lifecycle correctly, from alert creation and investigation to escalation, closure or referral. It verifies the workflow rules, data passed between systems, user permissions, audit records and failure handling against approved requirements. The aim is to establish that the software processes cases consistently and preserves evidence for review.

What AML case management workflow testing covers

A case management workflow usually starts when a transaction monitoring rule, customer screening result or manual action creates an alert. The system may then group related alerts, assign a case, request information, record investigation steps and route the case for approval or further action. A suspicious activity report (SAR) may be prepared or submitted through a separate process, depending on the organisation and jurisdiction.

Test the configured lifecycle as a series of states and permitted transitions. For example, a new case might move to 'assigned', 'under investigation', 'pending information', 'escalated' and 'closed'. Confirm that each transition has the right preconditions, required fields and authorised roles. Check that an incomplete investigation cannot be closed when policy requires supporting rationale or an approval.

Include the hand-offs to systems such as transaction monitoring, customer due diligence, sanctions screening, document storage and regulatory reporting where they form part of the actual workflow. Verify that identifiers, customer details, alert reasons and supporting records remain linked across those boundaries. This is a form of end-to-end testing in banking when the test crosses application or service boundaries.

Prepare scenarios and test data

Derive test cases from approved process requirements, decision tables and state transition rules. Include routine cases, edge conditions and prohibited actions. Useful scenarios include an alert assigned to the correct queue, a case reassigned after an investigator becomes unavailable, an escalation requiring a second reviewer, and a case that cannot be closed while mandatory evidence is missing.

Use controlled test data that represents relevant conditions, such as linked alerts, different customer risk ratings, incomplete customer records and screening matches requiring review. Prefer synthetic or appropriately anonymised data. Preserve relationships between records, and ensure the test environment cannot trigger live reporting, customer contact or operational holds.

Record the expected outcome for each scenario before execution. Specify the resulting case state, owner, queue, required fields, notifications and audit events. Where a rule or routing outcome depends on configuration, identify the relevant version and test environment. Environment drift, such as a changed queue mapping or user role, can make a result differ from the intended behaviour.

Execute the workflow and check controls

Run tests through the user interface and, where suitable, through service or application programming interface (API) checks. UI tests show whether an investigator can complete the work as intended. API assertions can confirm persisted state, linked records and event payloads, provided the interface is part of the supported test approach.

Check access controls at each sensitive action. An investigator should have only the permissions assigned to that role; an unauthorised user should not be able to approve or close a case by changing a request or calling an endpoint directly. For maker-checker controls, verify that the person who prepares an action cannot approve their own action where segregation rules prohibit it.

Exercise failure paths as well as successful ones. Test an unavailable downstream service, a rejected update, a duplicate alert delivery and a timeout during a state change. Confirm that retries do not create duplicate cases, partial updates do not leave inconsistent states, and failures are visible to the appropriate operational team. Check that a case can be recovered or safely retried without losing investigation notes or evidence.

Practical example

Suppose a transaction monitoring alert creates a case that requires an investigator review and supervisor approval before closure. Create a test customer and alert with the required links, then verify these outcomes:

• The alert creates one case with the expected identifier, reason and queue.
• The assigned investigator can add findings and attach test evidence.
• The investigator cannot approve their own closure request.
• A supervisor can approve the request, and the case reaches the configured closed state.
• The audit history records the actions, actors and timestamps, with no missing or altered investigation details.

Repeat the scenario with a missing required finding and with a duplicate alert message. The first should block closure with a clear validation response. The duplicate should follow the configured deduplication behaviour without silently dropping a distinct alert.

Assess results and retain evidence

Compare actual states and records with the expected results, including integration messages and audit events where available. Capture test data identifiers, configuration versions, execution results and relevant screenshots or logs. Link failures to requirements or control objectives so reviewers can see which workflow behaviour remains unverified.

Treat a passing screen-level test as insufficient evidence when the case state, downstream hand-off or audit record is also in scope. A release decision should account for unresolved defects in routing, access, data integrity or case history, with severity based on the impact of the affected control and workflow.