Transaction screening type
Salv screens transactions when the transaction screening API call is made.
💡 Unlike Person screening, where Persons are screened automatically daily and when an API call is made, Transactions are only screened when an API call is made. There is no regular automatic screening of Transactions.
If there is no match, an empty API response is returned. If there is at least one match, there is content in the API response and alert (or alerts) is created.
If there is a match that is cleared out by Clearance rules - the API response is empty, even though an alert with a Filtered status is created.
❗️Repetitive API calls for Transaction screening do generate new alerts, unlike Person screening, as a Transaction is meant to be screened only once.
Also, keep in mind that Transaction screening checks do not return unresolved Alerts from previous screenings. If you send multiple API calls for the same Transaction, each call will only provide information on Alerts generated by that specific call, not from previous ones.
One transaction per one screening event can generate multiple alerts, depending on the number of screenable fields, types of lists enabled and Clearance rules applied.
When an alert is created, a webhook (trigger: SCREENING_ALERT) can be setup to be sent with alert details.
Transaction screening configuration
Screening Flows
Transaction screening is configured through Screening Flows. Using Screening Flows, you can select specific name data fields from the data you provide, screen them against chosen list types, and apply them to specific Segments with a selected matching type. This setup gives you full control over your screening configuration.
For a complete introduction to Screening Flows, please refer to this article.
Goodlisting and Significant Update Indicators
In order to lower the number of unnecessary alerts, Salv remembers matches that have been closed as false positives and automatically goodlists them to avoid duplicate alerts, using an entity’s goodlist identifiers + matches for the goodlist record. You can select which information will be used for goodlisting (up to three parameters).
However, these matches are removed from the goodlist under two conditions:
when the status of the associated alert changes
when there’s an update to the list record
Not all list record changes are significant enough to revoke goodlisting; for instance, correcting a typo in record’s source description. Therefore, you can select which list record updates are significant enough to remove matches from the goodlist.
For more detailed information, please see here.