Screening Restricted Parties

Screening is a process whereby each individual or company (business partners) with whom you are planning to do business is screened against the restricted party list (denied, debarred and/or restricted parties) to check whether you can conduct business with them. Standard screening is performed based on first name, last name or company name. Additional optional fields like alternate name, address, postal code, city, province, and country can be used to determine the potential matches during screening. Oracle Global Trade Management (GTM) supports transactional and non-transactional screening of parties.

Government agencies throughout the world and other regional, unilateral, and multilateral agencies enforce regulations which restrict businesses and people from conducting trade with specific foreign entities (individuals, companies, countries). These entities are referred to as Denied, Debarred, and/or Restricted Parties. Typically, the restricted parties are mainly countries subject to embargoes, and persons, businesses, and organizations subject to financial sanctions. Periodically, these agencies publish lists of entities that are marked as restricted parties.

GTM provides the functionality to download this list from third party content providers and perform screening of involved parties against the list of "Restricted" parties identified by the government.

When you first download restricted parties into GTM from a content provider, you can compare all your parties in GTM to the entire restricted party list. As a content provider updates the restricted party lists, based on updates to the regulations, content providers will only send in the updates to the existing lists in GTM, also known as a delta list. At this time, GTM will then perform delta screening where all parties in GTM are screened against the delta list.

Performance Improvement Tips for Restricted Party List Screening (RPLS)

• Utilize Global Exclusion Service Preference Instead of Exclusion Words at the Service Preference Level
  In GTM, global exclusion words are used to filter out parties from RPLS. Stored in the Global Exclusion Service Preference and cached in memory, these words speed up processing by excluding matching parties before screening starts. This method is faster than using exclusion words at the Service Preference level, which slows down the screening process.
  • Set gtm.rpls.useExclusionWords = GlobalExclusionServicePreference to use Global Exclusion Service Preference.
• Utilize Service Parameter Level Thresholds
  The RPLS Service Parameter Threshold in GTM defines the limits for processing during screening. By setting forward and backward thresholds, you can optimize performance, better manage resources, and improve overall screening efficiency.
• Use Single User Data Source Profile
  A Single User Data Source Profile in GTM is a high-performance connection pool assigned to a single user, eliminating the need for additional Virtual Private Database (VPD) calls. This setup improves performance by reducing connection overhead and is ideal for high-speed data access scenarios.
  • To use this, log in to application and switch to User Role created which uses SINGLE USER data source profile. Please refer below on how to set up User Role for Single User Data Profile.
• Suppress Lifetime Events During RPLS
  Suppressing Lifetime Events in GTM prevents the generation of GTM_PARTY_LAST_SCREENING events after each RPLS. By suppressing these events, unnecessary event generation is avoided, resulting in better performance, especially during high-volume screenings.
  • Set gtm.rpls.suppressLifetimeEventsAfterScreeningDataUpdate = true to suppress GTM_PARTY_LAST_SCREENING lifetime events.
• Suppress the generation of CONTACT - RP SCREENING MATCH VALID, CONTACT - RP SCREENING ALL MATCHES INVALID and CONTACT - SERVICE EXECUTED events during each RPLS. By suppressing these events, unnecessary event generation is avoided, resulting in better performance, especially during high-volume screenings.
  • Enable the optional feature SUPPRESS RPS AND SANCTION SCREENING EVENTS to suppress the generation of CONTACT - RP SCREENING MATCH VALID, CONTACT - RP SCREENING ALL MATCHES INVALID and CONTACT - SERVICE EXECUTED events during screening.
• Improvements to the RPLS Service Process
  • Use Tasklist for Parallel Processing: Allows multiple tasks to be processed simultaneously, speeding up screening.
    • Set gtm.rpls.process.useTaskList = true to use Tasklist.
  • Avoid Lifetime Security Checks: Helps improve processing speed by bypassing unnecessary security checks.
    • Set glog.workflow.task.flags.ScreenPartyProcess = ABORT_ON_TIMEOUT,LOG_BATCHES,NO_LIFETIME_SECURITY  to avoid lifetime security checks.
    • On adding the new flag NO_LIFETIME_SECURITY, agent events raised by tasks circumvent entry point security checks.
  • Avoid Party Locking: Reduces delays caused by locking during bulk screenings, enhancing throughput.
    • Set  gtm.rpls.avoidLockingPartyForBulkScreening = true to avoid locking the parties during screening.
• Improvements to RPLS Screening via Agents
  • Use Single User Data Source for Agents: This ensures high-performance data access and reduces overhead during agent-driven screenings. To use this,
    • In the Automation Agent that runs Restricted Party Screening, set,
    • Run As = USER ROLE
    • User Role = <User Role created which uses SINGLE USER data source profile> 

By implementing these best practices, you can significantly enhance the efficiency and speed of the RPLS process in Oracle GTM.
 

Steps to setup User Role for Single User Data Profile

Managing Data Source Profiles

If the SINGLE USER profile is available to a customer, a DBA.ADMIN user must grant user role(s) access to it. The section on the Data Source Profile manager allows the superuser to decide which profiles are granted to which user roles and which are denied. For example, a customer may want a user role to have access to both the DEFAULT and SINGLE USER data source profiles; or they may want a user role to only have access to SINGLE USER. By default, all user roles have access to DEFAULT, even if not given an explicit grant. But by adding an explicit denial of the DEFAULT grant, a customer can better limit which profile a user role can choose.

Once a user role is granted to SINGLE USER, the user role can be modified on the User Role manager to change its default data source profile to SINGLE USER. Users then can be assigned a default user role pointing to SINGLE USER, or granted rights to that user role to change dynamically.

Note: This enhancement required we reopen the Data Source Profile manager back up to Administration users. The screen has been changed, however, to show only read-only header information and the user role grants. Data function assignments are not shown. See the Data Source Profile Security section below for more information on securing this feature.

User Roles for SINGLE USER Profile Access

Creating a user role that uses the SINGLE USER role is a three-step process:

1. Create the user role using the DEFAULT data source profile. This is the only profile available to all user roles.
2. Have a DBA.ADMIN user grant the new user role rights to the SINGLE USER data source profile. 
3. Edit the user role and change the data source profile to SINGLE USER.

Obtaining  a SINGLE USER Profile

The use of a SINGLE USER profile could theoretically double the connection needs for a customer. If half of a customer's work is with a user role assigned to SINGLE USER and the other half to DEFAULT, the system may fully use connections from both under heavy load.

For this reason, we do not provide use of the SINGLE USER profile out-of-the-box. A customer must request a CR from OPS to obtain the SINGLE USER profile, along with any requisite database resource increases needed for the new pools. The CR would contain three parameters:

1. What VPD user is needed for SINGLE USER. For a customer needing to optimize out all VPD predicates, this could be DBA.ADMIN. For one needing to avoid VPD.set_user round trips, it could be the primary planning user.
2. The maximum size of the SINGLE_USER_LOCAL_JTS pool. If omitted, this is set to the pod size of the LOCAL_JTS pool.
3. The maximum size of the SINGLE_USER_PRIMARY_THIN pool. If omitted, this is set to the pod size of the PRIMARY_THIN pool.

Relinquishing the Use a SINGLE USER Profile

A customer may no longer need the resources of the SINGLE USER profile. To relinquish it, they must request a CR from OPS. This would:

1. Remove all user role grants to SINGLE USER.
2. Switch any user role using the SINGLE USER data source profile back to DEFAULT.
3. Remove access to the SINGLE USER profile.
4. Release database resources granted for SINGLE USER access