Party Screening

This page is accessed via Master Data > Parties.

Any party (individual or company) defined in GTM can be screened against the restricted party list using the web, agent action, or process actions available in GTM. You can execute multiple screenings (e.g., BIS, OFAC, and Red Flag) with different service preferences on the same GTM party. Regardless of how you trigger it, the screening process executes the following steps:

1. Screening service gets the party and service preference as inputs.
2. Locks the Party.
3. GTM checks whether there is any restricted party data version or restricted party or service preference or exclusion list changes after the last screening date of the party. It continues with the next steps only if there is any change after the last screening date of the party or if the party was never screened earlier.
4. Retrieves the list of restricted parties based on the service preference and uses attributes like Data Source, Data Version, Agency Code, etc.
5. For every restricted party, the screening is performed for each service parameter configured in the Service Parameters page (e.g. first name, last Name, Company Name, Address, City, Country, etc). Screening of the service parameter with a higher threshold is performed before screening of the service parameters with a lower threshold in order to reduce the number of matches.

Note: Party data includes fields labeled Province and Province Code. When restricted party screening is performed, the Province field is compared to the State or Province field. If there is no data in the Province field, then the province code data will be screened against the State or Province field on restricted party data.

Note: To ensure better screening performance, keep the following in mind:
Use Country and/or City as service parameters with a non-zero threshold.
Use Content Source, Agency Code, and or Data Version lists as service preference parameters.
Use excluded words to reduce the number of unwanted matches.

6. Each service parameter is matched using the match engine specified in the Service Preference page and a match factor is determined.
   • UNKNOWN value on any field or XX value on Country Code field of the Restricted Party is treated as an empty value.
   • GTM considers a Restricted Party and party as NOT a match if there is empty value (including UNKNOWN) against any parameter for which Match attribute on the Service Parameter is configured as NO Match.
   • If the company name is configured as a parameter, GTM performs the screening using the company name and calculates the match factor. Then an additional screening is performed using the alternate name of the party and another match factor is calculated. The higher of the two match factors is considered as the resultant match factor for the parameter.

7. If the match factor value is less than the threshold specified in the Service Parameter page, the restricted party is assumed as not a match and screening against the restricted party is stopped. If the match factor value is greater than or equal to the threshold, an adjusted match factor is calculated.

Note: You can use the property gtm.rpls.prorateEmptyParamterWeight to exclude an empty parameter as part of the Overall Match Factor and hence, reduce the number of false positives returned during restricted party screening. When the property is set to "true" and the Match Default is MATCH, weightage of the empty parameters is prorated among the non-empty parameters while calculating the overall match factor and is then compared with the threshold on the service preference.
Overall Match Factor without prorating = Sum of weighted Match Factor for all non-empty parameters
Overall Match Factor with prorating = Sum of weighted Match Factor for all non-empty parameters/Sum of weight of all non-empty parameters

8. An overall match factor is calculated by adding all the adjusted match factors. The restricted party is considered as match only if the overall match factor is greater than or equal to the overall threshold specified in the Service Preference page.
9. All the matched restricted parties are saved against the party as a “POTENTIAL MATCH” and the status of the party is set as “REQUIRES REVIEW”. In case there are no matched restricted parties, the status of the party is set to “PASSED”.
10.  In case GTM finds any previous potential match of party as no longer a match, the status of the restricted party will be deleted.

Note: A status will be assigned when the screening process is completed. For more information about internal status designations, see GTM Internal Status Designations.

10. Lock on the party is released.

GTM supports the following restricted party screening:

1. • Web: Use this action to immediately trigger the screening process on a party and display the potential match results.
   • Agent: Use this action to trigger the screening process in the background, based on events. You can listen/subscribe to events like CONTACT – CREATED, CONTACT – NAME OR ADDRESS MODIFIED, LOCATION – ADDRESS MODIFIED.
   • Process: Use this action to perform mass screening of all parties.

Party Screening Examples

Following is a detailed explanation of the use of the screening options available in GTM for different business scenarios.

• Scenario-1: A Restricted Party List is available in GTM and a new GTM party is created. You can perform restricted party screening on this party using the web action or an agent action. This is called full screening since you are screening the party against the entire list of restricted parties.
• Scenario-2: A Restricted Party List is available in GTM and a GTM party is modified after a previous screening. You can perform a rescreening against the restricted party list using the web action or agent action. A full screening will be performed, i.e. screening of modified party will be performed on the entire list of restricted parties.
• Scenario–3: A Restricted Party List is available in GTM and all GTM parties are previously screened. There are no changes to party, service preferences, or the restricted party list. You can perform re-screening of the party against the restricted party list. Since there are no changes to the party, service preferences or the restricted party list, the screening is up to date and GTM will not perform any screening. This is also referred to as no screening.
• Scenario–4: A Restricted Party List is available in GTM and all GTM parties are previously screened. A user decides to modify the service preference (e.g. updating the exclusion words, changing the punctuation marks, modifying the screening field parameters, changing the individual field threshold or overall threshold, etc.). Since the service preference was changed, you will need to perform re-screening of all parties. GTM will perform screening on each party against the entire list of restricted parties. You can perform this by using the Restricted Party Process page and selecting all the parties for screening.

• Note: This process is a full screening of the entire party master against the restricted party list and hence, the system could take time to complete the whole process.

• Scenario–5: A Restricted Party List is available in GTM and all GTM parties are previously screened. A user downloads the latest restricted party list and there are new or modified restricted parties added to the existing restricted party list. You will need to perform re-screening of all the parties against updates to the restricted party list. GTM will perform screening of each party against the updates to the existing list, also called the delta list of restricted parties. This screening is also referred to as delta screening. You can perform this by using the Restricted Party Process page and selecting all the parties for screening.
• Scenario–6: A Restricted Party List is available in GTM and all GTM parties are previously screened. A user downloads the new restricted party list. This list is a replacement of a previous restricted party list, has a new data version, and is marked as the current list. You will need to perform re-screening of all parties against the entire new restricted party list. GTM will perform screening of each party against the entire new list of restricted parties. This is also referred to as full screening. You can perform this by using the Restricted Party Process page and selecting all the parties for screening

• Note: This process is a full screening of the entire party master against the restricted party list and hence, the system could take time to complete the whole process.

• Scenario–7: A Restricted Party List is available in GTM and all GTM parties are previously screened. If you already performed restricted party screening against this list, GTM would not perform any screening as there is no change in data between the current and the previous screening. However, if you want to perform a force screening, you can modify the service preference update_date attribute via backdoor SQL. Once this is done, you can perform screening of each party against the entire new list of restricted parties. This is also referred to as full screening. You can perform this by using the Restricted Party Process page and selecting all the parties for screening.

You can turn on the GtmPartyScreen log before screening and identify from the logs whether a full screening or delta screening was performed. For example, the logs show that the party was last screened on 2014-03-11 10:41:50 UTC and after that there was no change to the party, service preference configurations, data version or exclusion list. Hence, full screening was not performed; but the last change made to some denied parties was on 2014-03-11 10:43:48 UTC and hence, the delta screening was performed against all those denied parties changed between the 2014-03-11 10:41:50 UTC and 2014-03-11 10:43:48 UTC.

Note: This is for diagnostics purpose only and should be rarely used.
Turn off the GtmPartyScreen log after verifying the kind of screening.