When a Person or Transaction is screened against a custom list for the first time, they are checked against all records in that list. In subsequent screenings, only new or updated list records are checked.
Not every update to a custom list record is meaningful. For instance, correcting a typo in a notes field probably shouldn't cause a full re-screening. Significant Update Indicators (SUIs) let you decide which field changes in your custom list records are important enough to warrant one.
What is a full re-screening? When a Person is fully re-screened, any previous decisions on their alerts are not taken into account and new alerts are generated. That means alerts from previous screening events may be raised again (if there is a match), regardless of how they were previously resolved.
For Transaction screening, a significant update in a list record removes the match from the goodlist, meaning a new alert can be generated on the next transaction.
Where to find it
The Significant Update Indicators section is located on each Custom List configuration page, directly below the Schema fields table.
Each schema field in your list is shown with two columns: Person and Transaction. A green checkmark (β) indicates that a change in that field is treated as a significant update for that screening type. A dash (β) means changes to that field are not considered significant.
Configuring SUIs
To edit which fields are considered significant, click the Edit button in the top-right corner of the Significant Update Indicators section.
A dropdown will appear with two options:
Person: configure which field changes cause a full re-screening of a matched Person during the next screening event
Transaction: configure which field changes remove a match from the goodlist in Transaction screening
Select the screening type you want to configure. A modal will open β Significant Update Indicators for [person / transaction] β listing all schema fields in your custom list with a checkbox next to each.
Checked fields: a change in this field is treated as a Significant Update
Unchecked fields: a change in this field does not cause re-screening or goodlist removal
π‘ SUIs can only be configured at the top-level field. If a field has child fields defined β for example, an address field with city and street as children β marking address as significant will capture any change within it, but you cannot configure address.city or address.street individually.
Once you've made your selections, click Save.
π‘ When you add a new field to your custom list schema, it is automatically marked as a Significant Update Indicator for all screening types. This means changes to that field will immediately cause re-screening or goodlist removal. If this is not intended, review your SUI configuration after any schema changes and uncheck the fields you do not want to be significant.
Person screening
When a custom list field marked as significant is updated, the Person will be fully re-screened during the next screening event (either a scheduled daily screening or a new API call).
Example:
Your custom list has a field
str_status(Has STR filed), configured as a Significant Update Indicator for Person screening.A Person - let's call them Alex - was previously screened against this list. An alert was raised and closed as a false positive.
The
str_statusvalue for the matching list record changes fromNotoYes.Because
str_statusis a Significant Update Indicator, Alex will be fully re-screened in the next screening event, regardless of the previous false positive decision.
Transaction screening
Significant Update Indicators for Transaction screening work together with Goodlisting.
When a transaction is screened and the resulting alert is closed as a false positive, it is added to the goodlist (if applicable) to prevent duplicate alerts. However, if a field marked as significant is updated in the matching list record, the match is removed from the goodlist β meaning a new alert can be generated for the next transaction involving the same entity.
Example:
Your custom list has the
countryfield configured as a Significant Update Indicator for Transaction screening.A transaction from entity "Company Ltd" matched a record in your list. The alert was closed as a false positive and goodlisted.
The
countryfield of the matched list record is updated.Because
countryis a Significant Update Indicator, the goodlist entry is removed. The next transaction from "Company Ltd" matching this record will generate a new alert.
Tips
If no fields are marked as significant, updates to list records will never trigger re-screening or goodlist removal. This means changes to your list β including risk-relevant ones β will go undetected. If your custom list is actively used for screening, it is strongly recommended to have at least some fields configured as SUIs.
You can configure SUIs independently for Person and Transaction screening - a field can be significant for one but not the other.
Review your SUIs after making schema changes to your custom list. The banner at the top of the configuration page serves as a reminder: "Review Significant Update Indicators after schema changes to ensure changes are reflected in your SUI configuration."
Fields that carry identifying or risk-relevant information (such as names, status flags, or addresses) are typically good candidates for SUIs. Supplementary fields like notes or internal reference numbers usually are not.
