On-Demand Customer Rescreening

Last updated: August 26, 2026

Introducing On-Demand Customer Rescreening 🚀

We're excited to introduce the new On-Demand Customer Rescreening feature, which allows you to instantly check for changes in your customers' risk profiles as and when you need to.

What is On-Demand Customer Rescreening?

This feature provides a dedicated API endpoint that allows you to trigger an immediate rescreening of a specific customer against all applicable watchlists and profiles in the ComplyAdvantage database. The rescreen applies the monitoring configuration assigned to that customer. If no monitoring configuration is assigned, it falls back to the screening configuration that was applied when the customer was first screened.

Why is This Feature Important? (Impact)

Financial institutions must continuously monitor their customers' risk profiles. Previously, when you updated a customer's record (e.g., new identity info, an account becoming active), you would have to wait for the next scheduled daily monitoring run to see if that change impacted the screening results.

This new on-demand rescreening feature eliminates that delay, enabling you to:

Instantly Assess Risk: Immediately check for changes in screening results when a customer's information is updated on your side.
Enhance Operational Efficiency: Get real-time feedback on your customer data changes rather than waiting for a batch job.

How to Use On-Demand Customer Rescreening

This feature is available via a new API request, which is ideal for integration into your internal workflows.

When to Use It

You should trigger an on-demand rescreening in scenarios where a change to your customer's data might affect their risk profile, such as:

When a customer's key details are updated.
When a previously dormant client becomes active and monitoring is switched back on.

API Requirements & Response

To initiate an on-demand rescreen, you will need to call the dedicated API endpoint:

Requirement	Detail
Prerequisites	The customer must already have been screened.
Account access	Your account needs Account has access to monitor on demand functionality enabled. Ask your Customer Success Manager if you are not sure whether it is switched on.
API endpoint	`POST /v2/customers/{customer_identifier}/workflows/sync/rescreen` on `https://api.mesh.complyadvantage.com`. Full reference: Rescreen a customer synchronously.
Required parameter	`customer_identifier`, a UUID in the path. This is the identifier Mesh generated when the customer was created, not your own external identifier.
Optional query parameter	`rescreen_type`. `DELTA` is the default and the only accepted value. It runs a differential screen, comparing the new result against the customer's previous screening baseline and alerting only on new or changed risk factors.
Optional header	`X-ComplyAdvantage-Idempotency-Key`, up to 255 characters. Using it is recommended to ensure safe retries without duplicate processing or billing. Generate a new key for every distinct rescreen, and send the same key when you retry a failed request.
Request body	None. This endpoint declares no request body.
Search volumes	Rescreen events count towards your total onboarding search volumes.

Upon calling the API, the system will rescreen the customer and check for changes in the screening results. The API will return the following key information in the workflow response:

Field	Description	Notes
`workflow_instance_identifier`	A unique identifier for this rescreen run.	UUID.
`workflow_type`	The type of workflow that ran.	`rescreen-customer` for this endpoint.
`status`	The status of the workflow as a whole.	One of `NOT-STARTED`, `IN-PROGRESS`, `COMPLETED`, `SKIPPED`, `ERRORED`.
`steps`	The steps this workflow runs.	The API reference examples show `customer-rescreening` followed by `alerting`.
`step_details`	A map keyed by step name. Each entry carries its own `status`, `identifier`, `error_message` and `step_output`.	Read a step's status before reading its output.
`step_details.customer-rescreening.step_output.rescreening_result`	The outcome of the rescreen.	The API reference shows `HAS_CHANGES` when the differential screen finds changes and `NO_CHANGES` when it does not. This field is documented by example rather than in the schema, so treat the values as indicative.
`step_details.alerting.step_output.alerts`	The alert entries produced by the alerting step, each with its own identifier.	Empty when no alert was raised. The key is absent altogether when the alerting step was skipped or errored, so check that step's status first.

System Behaviour & Audit Trail

A rescreen has three possible outcomes. Read status first, because the HTTP call succeeding is not the same as the rescreen succeeding.

Changes detected. rescreening_result is HAS_CHANGES and the alerting step returns one or more alert entries. A monitoring alert is raised against the customer so your team can review what changed. The response gives you the alert identifier. It does not return a case identifier, so if you need the case, take it from the CASE_ALERT_LIST_UPDATED webhook.
No changes detected. rescreening_result is NO_CHANGES and the alerts list is empty. Nothing is raised and no case is created.
The workflow errored. The endpoint can return HTTP 200 while status is ERRORED. When that happens the customer-rescreening step carries an error_message and the alerting step is skipped. Treat this as a rescreen that did not run, not as a clean result.

A request the API cannot accept returns HTTP 400 with a problem-detail body describing what was wrong.

All rescreen events are fully tracked:

The event will be saved in the audit log.
It will show if changes were detected
It will be visible in the customer audit view