What options do I have to optimize my screening results?

Screena’s core screening configuration applies to every client equally, but custom components consider a client’s specific screening strategy.

While libraries are a crucial first step in optimizing your screening results, Screena offers a range of advanced rules and options tied to distinct API keys, allowing you to fine-tune every aspect of the screening engine beyond the libraries.

Screena Components-Based Screening Architecture

Libraries

Screena allows users to build their own libraries of stopwords, synonyms, prefixes or suffixes. You can provide your own libraries (i.e., custom libraries) to either replace or supplement the default ones (i.e., core libraries).

Libraries are paramount to keep false negatives rates as low as possible, as they are used in the name normalization process and ensure consistency in how your data is matched. For example, synonyms will help to determine which names should be considered equal despite being syntactically dissimilar.

Libraries can be managed independently. There is no need to populate all of the libraries in one go (i.e., prefixes, suffixes, synonyms, and stopwords) through a single API call. For example, it is quite possible to populate prefixes all while leaving suffixes unchanged when calling the method to populate Libraries.

You can check our API Reference Guide for more information about Libraries.

Stopwords for Name Matching

This library is designed to prevent the matching of specific terms contained within narrative fields that add no meaning to names (e.g., 'of', 'markets', 'final payment') against the sanctions lists, thus reducing false positives.

You can manage the list of stopwords for name matching by importing JSON or CSV files.

Changes to the library of stopwords for name matching are considered low-medium risk but full regression testing is recommended to ensure no false negatives are inadvertently produced.

Stopwords for Identifier Matching

This library is designed to prevent the matching of specific terms contained within narrative fields having the same structure as BIC8 or BIC11 codes (e.g., 'language', 'february') against the list of blacklisted countries, thus reducing false positives.

You can manage the list of stopwords for identifier matching by importing JSON or CSV files.

Changes to the library of stopwords for identifier matching are considered low risk as they don’t affect the name-matching logic on sanctions lists.

Stopwords for Geo-Matching

This library is designed to prevent the matching of specific terms contained within narrative fields against the library of high-risk locations (e.g., ‘CAF Bank’ against the country code ‘CAF’, ‘imran’ against the country name ‘Iran’), thus reducing false positives.

You can manage the list of stopwords for geo-matching by importing JSON or CSV files.

Changes to the library of stopwords for geo-matching are considered low-medium risk but full regression testing is recommended to ensure no false negatives are inadvertently produced.

Prefixes

This library is designed to discard specific terms placed "before" a name such as titles or honorifics (e.g., 'Dr'), academic qualifications (e.g., 'M.D.'), and organization designators (e.g., 'The Bank') when matching names against the sanctions lists, thus reducing false positives.

You can manage the list of prefixes by importing JSON or CSV files.

Changes to the library of prefixes are considered low-medium risk but full regression testing is recommended to ensure no false negatives are inadvertently produced.

Suffixes

This library is designed to discard specific terms placed "after" a name such as qualifiers (e.g., 'Jr') and legal forms of companies (e.g., 'LLC') when matching names against the sanctions lists, thus reducing false positives.

You can manage the list of suffixes by importing JSON or CSV files.

Changes to the library of suffixes are considered low-medium risk but full regression testing is recommended to ensure no false negatives are inadvertently produced.

Synonyms

This library is designed to enforce the matching of names like alternative spellings, nicknames, diminutives (e.g., '20th' and 'Twentieth', 'Bill' and 'William', 'Ronald' and 'Ron') against the sanctions lists, thus reducing the risk of false negatives.

You can manage the list of synonyms by importing JSON or CSV files.

Changes to the library of synonyms are considered low risk. While they influence the name-matching logic on sanctions lists, they are intended to minimize the occurrence of false negatives. Conversely, the likelihood of increasing false positives is also low.

Whitelisted Aliases

This library is designed to whitelist specific watchlist aliases that are deemed of low quality but are not specified as such on the watchlists (e.g., the alias 'Alexander' on the Consolidated Canadian Autonomous Sanctions List).

You can manage the list of whitelisted aliases by importing JSON or CSV files. The files should include the watchlist, the alias, and the alias’ unique identifier as specified on the watchlist.

Changes to the library of whitelisted aliases are considered low risk as they don’t affect the name-matching logic on sanctions lists. They just reduce the scope of watchlist aliases when screening names.

Private Lists

In addition to the public watchlists, you can also upload your own private watchlist.

Private lists are lists of names or entities that are created and maintained by an organization for its own internal screening purposes. Private lists are not publically available or shared with others, and they typically contain names or entities that are specific to the organization's business operations, risk tolerance, or compliance requirements.

Data contained in private watchlists are treated as personal data encrypted with a password encryption key and remain inaccessible to Screena.

You can manage additions to or removals from the private list by importing a CSV file.

To learn how to upload your private list into Screena, check the answer to this question: Is there a template to upload private lists into Screena?

Changes to the private list are considered low risk as they don’t affect the name-matching logic on sanctions lists.

Rules-Based Algorithms

Rules-based algorithms are deterministic name-matching rules such as traditional edit-distance algorithms (e.g., Jaro) or other proprietary algorithms designed to detect specific name patterns including, but not limited to: name order variations; missing name components; misspellings and errors; name concatenations; acronyms and initials; detection of address and geolocation elements within narrative fields; noise detection, etc.

To activate or deactivate any rules-based algorithms for your Screena subscription, contact [e-mail].

Changes to rules-based algorithms are considered high risk. Full regression testing is recommended as such changes can potentially increase the risk of false negatives and false positives.

AI Models

Training of AI models is designed to increase the accuracy of name-matching prediction scoring when simple deterministic rules are not enough to retain or reject candidate hits immediately.

Screena AI training is based on supervised learning using labelled name datasets. The work of our R&D team is based on new data and clients' feedback. If you would like to share your insights and optimize your screening results, contact [e-mail].