If you're curious and want to know what happens behind the scenes when Salv screens for sanctions, PEP, and adverse media hits, here's a brief explanation of what happens when screening runs.
💡 All screenings performed by Salv are based on the Screening Flows you set up. Screening Flows allow you to configure the data to be screened, specify matching types, choose list types, and manage Segment inclusions and exclusions.
❓ When is screening performed?
Daily: All Persons (if not exempted from Automatic Re-screening) are screened automatically every day. Automatic Re-screening is performed between 1-4 am (GMT+2).
API call: Persons can also be screened on demand with an API call. The same screening configuration is applied as in the Automatic Re-screening.
Transaction screening:
API call: Transactions, as opposed to Persons, are only screened when an API call is made.
Screening is performed using the latest updated versions of Dow Jones lists or Custom lists. Dow Jones lists are updated within 24 hours.
Screening process
1. Data Ingestion
The initial step involves ingesting data from two main sources:
Your Data: Information provided by you - Person and Transaction data.
List Data: Dow Jones, BMMG, or data from a Custom list created by you.
🔄 A bit on Dow Jones list updates:
Lists are updated at least one time per day incrementally, and once every two weeks a completely fresh full list update is performed.
Whenever any single one of those updates fails, the entire Screening team is notified, and a on-call support engineer is assigned to investigate the cause.
If the list updates have not been performed for 24 hours, it is considered an incident, and a relevant warning will be shown in UI for all clients.
2. Screening Exclusion Check
Before processing the data, our system checks whether the screened entity, whether a Person or Transaction, belongs to a Segment that has been excluded from screening.
3. Data Preprocessing
The preprocessing step normalises and prepares both your data and list data for screening:
Normalisation: Converts all entries to a standardised format (e.g., lowercase, standard tokenisation, ASCII folding).
Cleaning: Specific adjustments such as removing unnecessary or obstructive characters and standardising entries for uniformity.
For example, company name
Super Šipping Company Ltd ?would be transformed intosuper,sipping,company,ltd,xafter data preprocessing.
Currently, we support both Latin and Cyrillic alphabets. For Cyrillic, we perform transliteration during preprocessing and only the transliterated version is screened.
4. Search
During this phase, our system searches for potential matches between your data and list data using Elasticsearch.
Before conducting the search, we remove any stopwords - common terms found in company names - identified through an analysis of the Dow Jones index. By eliminating words such as corporation, limited, plc, societas, uab, sia, etc., we improve search accuracy and reduce false positives.
For name screening, the search mechanism employs advanced algorithms to enhance accuracy:
Levenshtein Distance: This algorithm allows for controlled fuzziness in matches, adjusting the permissible edit distances based on word length.
Soundex: This algorithm focuses on phonetic similarities, matching names that sound alike even if they are spelled differently.
Elastic's Relevance Algorithm: This algorithm evaluates the relevance of matches, considering factors such as name length, uniqueness, and the number of matches.
For reference screening, the search is utilising:
Levenshtein Distance: Allows for controlled fuzziness, similar to name screening, but with different settings.
Binary Relevance: This algorithm ensures that every token from the list is present in the input.
5. Scoring (Fuzzy matching only)
Only applicable to flows where Fuzzy or Fuzzy contains matching types are selected, this step involves applying a scoring mechanism to assess the closeness of potential matches.
Scoring Algorithm: Jaro-Winkler scoring algorithm is used to quantify the similarity between data entries.
💡 You can read in detail how search and scoring steps are conducted in this screening hit example.
6. Goodlisting
Goodlisting is a crucial step designed to reduce false positives by excluding known safe matches from alerts:
Person Screening:
All matches are compared against previous screenings of the same person.
If no significant change has taken place since the last screening event, no manual review alerts are generated.
If there has been a significant change, new manual review alerts are generated if there are matches.
Transaction Screening: Salv remembers matches that have been closed as false positives and automatically goodlists them to avoid duplicate alerts, using an entity’s goodlist identifiers plus matches for the goodlist record.
7. Clearance Rules
This step involves applying Clearance Rules that can automatically resolve and close alerts if they meet certain conditions. Based on specific criteria, some matches may be automatically dismissed if they conform to trusted patterns or known safe scenarios.
If the matches are filtered by the Clearance Rules then the alert status is marked as FILTERED, which means it does not need a manual review.
If the Clearance Rules did not affect the matches, then the alert is created with its status as NEW, which means this alert needs a manual review.
8. Alert Generation
For all matches that do not meet exemption, goodlisting, or clearance criteria, alerts are generated:
Manual Review Needed: These alerts signify potential risks that require manual investigation by compliance personnel or analysts to determine the appropriate action.
💡 You can read about Screening alert handling here.