Before a Screening Flow change goes live, you can test it against historical data to see how it would have performed, without affecting production screening or generating real alerts.
What Can Be Tested
Only draft versions of a Screening Flow can be tested. Live versions cannot be tested directly.
If you want to test how a currently live Screening Flow would behave with a change, first duplicate it as a draft, then test the draft. See here for how to create a draft from a live flow.
Drafts Lock Once Tested
Once a draft has been tested at least once, it can no longer be edited. This is to make sure a test result always reflects the exact configuration it ran against - you can't run a test and then quietly change the flow underneath it.
If you want to make further changes after testing, create a new draft (by duplicating the live flow, or recreating the tested draft) and continue testing from there.
Running a Test
Open the draft you want to test.
From its ⋯ action menu, select Run test.
In the Add new test dialog, configure the following:
1. What to test
Pick the entities - persons or transactions - to run through this flow.
By date range: select a
From createdandTo createddate to test against all entities created in that period.For Transaction Screening Flows, you can additionally check Use only screened transactions to limit the test to transactions that were already screened.
For Person Screening Flows, you can additionally check Use only automatically re-screened entities, which excludes persons in Segments that are excluded from automatic re-screening.
By id: enter specific Entity IDs to test a particular set of records instead of a date range. You can paste a comma separated list here.
2. Screening behaviour
Choose how closely the test run should mirror production:
Match my live screening: runs exactly as production would today.
Clearance rules: all live versions are applied.
Goodlisting: only affects records matching past goodlisting decisions:
Person screening flows: only affects persons screened before - reuses past goodlisted alerts for the same person and list record.
Transaction screening flows: only affects transactions matching past goodlisting decisions (based on goodlisting keys).
Read more about person goodlisting and transaction goodlisting.
Customise: change clearance rules or goodlisting for this test:
Clearance rules: choose All live (current) to apply every live clearance rule, or Pick rules to select individual rules to apply for this test run.
Goodlisting: check Apply goodlisting to reuse past goodlisting decisions for this test run.
Once configured, click Run test to start the test.
How Tests Run
Tests run one at a time. If a test is already running for your account, additional tests you start are scheduled and will run automatically once the previous one finishes.
Viewing Test Runs
To see all test runs for a draft, open its ⋯ action menu and select Test runs.
This shows every test run against that draft, including:
ID — the test run identifier
Status — e.g. Finished
Created — when the test was started
Duration — how long the test took to run
Records — the date range or entity IDs tested
Goodlisting — whether goodlisting was applied
Screened only — whether the test was limited to already-screened records
From here, click View results on any test run to open its results dashboard.
Results Dashboard
The Screening test results page shows how the tested draft would have performed against the records you selected.
Overall statistics
A high-level summary of the run:
Entities screened — the number of records the test ran against.
Matching rate — the percentage of screened entities that produced at least one hit.
Hits — the total number of hits found against the selected lists.
Alerts — the total number of alerts that would have been generated.
ℹ️ A hit is a single match against a list entry. An alert is a group of hits — hits are grouped into one alert when they share the same Screening Flow and entity. So one alert can contain multiple hits (e.g. several list entries matched for the same person in the same screening run), which is why the number of alerts is typically lower than the number of hits.
Alert funnel
Shows what would have happened to the alerts generated, based on the Screening behaviour settings chosen when the test was run:
Alerts — total alerts generated (same figure as in the overall statistics).
Cleared by clearance rules — alerts that would have been automatically cleared by clearance rules.
Goodlisted — alerts that would have been automatically resolved via goodlisting.
Read more about person goodlisting and transaction goodlisting.
Remaining for manual review — alerts that would still need a human decision.
Stats %
A chart breaking down the alert funnel outcomes as percentages of the total (e.g. what share of alerts ended up in manual review vs. cleared vs. goodlisted), so you can see the split at a glance rather than just raw counts.
Fuzzy matching score split (if applicable)
A chart showing the distribution of fuzzy matching scores across all hits found in the test (score on the x-axis, number of hits at that score on the y-axis). This helps you see, for example, whether hits are clustering near your matching threshold.
Clearance rules
The Clearance rule impact table shows how each clearance rule performed in the test, with one row per rule (and per version, if a rule was tested at both its current live version and a draft version — these appear as separate rows with the same rule summary and handle, distinguished by the Version column).
This lets you see not just whether your Screening Flow draft performs as expected overall, but which individual clearance rules are driving that outcome — useful when comparing a live rule against a draft version of the same rule side by side.
List match breakdown
The List group hit count table breaks down all hits by the list they came from — showing, for each List Group, List Provider Code, and List Type, how many hits were found. This gives a quick view of which lists are driving the results (e.g. how many hits came from PEP vs. Sanctions (and different sanction providers and groups) vs. Adverse Media vs. your own Custom Lists).
Matches examples
Below the list breakdown, you'll find example matches grouped into a table per list type (SANCTION, PEP, ADVERSE MEDIA, ADVERSE MEDIA ENTITY, CUSTOM LIST). Each table lists individual hits with details such as the alert and entity they belong to, the screened value, the matched list entry, the match score, and the underlying list record — useful for spot-checking whether the matches your draft is producing actually make sense.