Using Screening Functionality

Screening of entities in Fenergo SaaS is conducted through integration to one or more third party screening providers. Screening can be distinguished between On Demand Screening, where a request is triggered from within Fenergo SaaS as part of a journey, and Ongoing Screening, where an alert is triggered outside of Fenergo SaaS based on an update from the screening provider.

Fenergo SaaS supports screening of the following match categories:

• PEP
• Sanctions
• AdverseMedia
• Enforcements
• Other

This User Guide offers an overview of the functionality provided by Fenergo SaaS for On Demand Screening.

Refer to the specifics of each supported provider in the respective configuration guide:

• LexisNexis Specifics User Guide
• WCO Specifics User Guide
• Grid Specifics User Guide

On Demand Screening

Journey Task: Screening Scoping

This is an automated task that runs the Scoping Rules that are configured in the Screening Scoping Rules Configuration to determine which entities in the hierarchy are screened.

If this task is not included in the Journey configuration, or if no valid Scoping Rules have been configured, all entities in the hierarchy will be screened.

Journey Task: Screening Entity Selection

As well as automated Scoping Rules, a manual screening scoping task can be inserted into a journey to allow users to manually select entities to bring in or out of scope for screening. This is an optional step that some clients may choose to use to give users some control over who is screened in addition to what is determined by the rule sets. The manual scoping task does not require the automated scoping task to be used, and vice versa. However, if the automated scoping task is run prior to the manual scoping task, the entities that have been determined to be in scope by the rule sets will be pre-set to In Scope.

The Screening Entity Selection task displays the hierarchy structure and allows a user to select entities to bring in or out of scope for screening.

Entities can be selected in bulk by using the checkboxes, which will expose icons to set the selected entites as In Scope or Out of Scope.

Indiviudal rows can be actioned by mousing over the right-hand side of the row to expose the icons.

For the screening entity selection task to be completed, it is required to have at least one entity included in the scope.

Journey Task: Initiate Screening

This is an automated task that orchestrates the screening search request to the screening providers selected through configuration.

The credentials and provider-specific settings will also be defined in the configuration as described in the Screening Configuration User Guide.

Where more than one entity is being screened as part of the journey, a single Batch request is created which contains the list of entities that are passed to the screening providers. This will be based on the entities determined to be In Scope by the Scoping Rules and/or Screening Entity Selection tasks if these tasks are in use.

There is no user action required for this task.

Journey Task: Screening Match Resolution

This task presents the results returned from the screening search request and allows the user to determine whether the results are matches or false positives.

If no results are returned for any of the entities that are screened, the system will auto-complete the task and no user action is required. An exponential backoff mechanism is implemented for auto-completion, allowing sufficient time for screening providers to complete the search process. This mechanism can extend the wait time for results, up to a maximum of 7 days.

The list of results is presented in the Screening Results table.

Screening Results:

The Screening Results table displays the key data returned from the provider for each of the results.

Clicking the expand icon for a particular result will expand the row to display the data that has been returned from the screening provider.

Key Data: Contains the key data that is most useful in identifying whether the result is a match or not. It includes Names, Addresses, Aliases, Dates of Birth, Gender, and Nationality/Citizenship data.

Profile: Contains more extensive profile or biography data relating to the entity. This will differ depending on which provider the results are returned from but will typically include a history or biography of the entity, as well as information on why they have been listed in the screening database. The Profile section would typically only be used if a user is unable to make a determination based on Key Data alone, or to conduct an assessment of a confirmed match.

Relationships: Contains data on associations of the entity, which may be individuals or companies.

Sources: Contains links to sources of information related to the result.

Individual Match Resolution

Click the expand icon for a particular result to expand the row and review the data contained within each tab.

Select a Resolution status from the following options:

• Match: The user is satisfied that the result relates to the entity that has been searched.
• No Match: The user is satisfied that the result does not relate to the entity that has been searched.
• Unresolved: The user is unable to make a determination at this point.

Note: All results should be resolved as either a Match or No Match before the task is completed. The system will run a validation to ensure no results have a status of Unresolved when the user clicks the Complete button.

Select a Reason value from the available drop-down options. The available options differ depending on the selection of the Resolution field.

The Comments field can be used to include additional commentary as to how the user made their determination, or any other information related to the result or the match resolution process. This can be useful to store from an audit perspective.

Click Resolve. This saves the data for that record and the Status is updated.

Bulk Match Resolution

Use the checkbox to multi-select the records to be resolved.

Click the resolve icon to expand the Resolution drawer.

Select a Resolution status, Reason and enter any additional Comments.

Click Resolve. This saves the data for that record and the Status is updated.

Once all results have a status of Match or No Match , click Complete to complete the task.

History

As well as results for the current screening search which are displayed under the Current Hits tab, historic screening searches that have been conducted for the same entity can be viewed in the History tab.

Clicking on a record in the History tab will open a modal displaying the Screening Results table for that particular search. This includes the data that was returned from the provider and the match resolution details recorded by the user. Only hits with a Status of Match will be displayed in the History tab.

Journey Task: Confirmed Match Verification

This task is a pre-defined decision gateway that houses conditional logic to determine whether any confirmed matches have been identified during the match resolution process. The primary purpose of this is to determine whether or not to trigger the Materiality Assessment task, however, it can be used to drive any conditional tasks that should be triggered where confirmed matches have been identified.

Confirmed Match Verification checks the result records for the previously completed Screening Results task for any records where Status = Match. The Yes branch determines what action should be taken where Confirmed Match Verification = Yes.

In the below example, the decision gateway is determining that the Materiality Assessment task should be triggered if Confirmed Match Verification has identified that there are result records where Status = Match. If no results have Status = Match, the Materiality Assessment task would be skipped.

Journey Task: Materiality Assessment

The Materiality Assessment task is designed to capture the overall outcome of the screening process. It allows a user to view a summary of all confirmed matches, and to make a determination as to whether the matches are material or not in the context of the client entity. It can also be used to drive additional processes such as risk and escalation tasks.

The Materiality Assessment task is composed of two panels: Screening Results and Review Details.

Screening Results:

The Screening Results table displays a list of confirmed matches as determined during the match resolution process. The structure of the table is the same as it appears in the Screening Results task, however, the data is not editable and results that have been resolved as false positives are not displayed in this context.

Review Details:

The Review Details panel contains the fields that allow the user to capture the outcome of the screening process. The fields that appear here are driven by the Policy configuration for the tenant. There is a short guide to configuring these fields at the end of this section.

The default configuration for the Review Details panel consists of the following fields:

• Sanction Status: The overall materiality of confirmed Sanctions hits in the context of the client entity.
• PEP Status: The overall materiality of confirmed PEP hits in the context of the client entity.
• Adverse Media Status: The overall materiality of confirmed Adverse Media hits in the context of the client entity.
• Enforcement Status: The overall materiality of confirmed Enforcement hits in the context of the client entity.

The user can select from the following options:

• Material: The confirmed screening hits in this category have a material impact on the client entity.
• Immaterial: The confirmed screening hits in this category do not have a material impact on the client entity.
• None: There are no confirmed screening hits in this category.

The values that are selected in the Review Details panel are used to drive subsequent tasks:

• Risk Assessment: The materiality status per screening category is used to feed into the overall risk assessment calculation. Please see Risk User Guide for details on how to configure risk factors.
• Conditional Tasks: Conditional tasks such as escalations to senior managers or Enhanced Due Diligence can be triggered by the materiality status. Please see Journey User Guide for details on how to configure conditional tasks.

Sample Configuration

This section describes how to configure the Review Details fields using the default configuration. The entries and values can be amended as required. Please refer to the Policy User Guide for full details of how to configure a policy.

1. Add Materiality Assessment as a Requirement Category in the Reference Data Editor.
2. Add a new Materiality Status lookup in the Reference Data Editor with the following entries: a. Material b. Immaterial c. None
3. Navigate to the appropriate Policy and add Data Requirements for the following fields: a. PEP Status b. Sanctions Status c. Adverse Media Status d. Enforcement Status
4. Select Materiality Status as the Lookup value and Materiality Assessment as the Category for each of the above fields.
5. Navigate to any Journey that you wish to configure the Materiality Assessment for.
6. Select Materiality Assessment as the Business Category for the Materiality Assessment task. The Review Details panel will be populated with the configuration that has been mapped to the Materiality Assessment category.

Journey Task: Return Screening Results to Providers

When results are generated by the screening provider, they remain as open alerts until they are closed with a resolution status.

After the user completes the match resolution process in Fenergo SaaS, the resolution status must be returned to the screening providers in order to close the alerts.

This is an automated task that orchestrates the return of resolved screening results to the screening providers defined in the configuration.

There is no user action required for this task.

Reopening Screening Processes and Screening Resolution Reuse

In the context of a journey, the screening process may occasionally need to be reopened for corrective actions.

Conditions for Reopening

Users can reopen any tasks that occur before the screening process begins. Once the screening process has started, only tasks prior to the screening can be reopened.

Process Overview

When reopening a screening process within the same journey, the following occurs:

• Updating Resolutions: Matching hits will be updated with the resolution, reason, and comments from the most recent resolution made by the user. This ensures that any previously resolved hits carry over the latest resolution.
• Latest Resolution: Once the resolution for a hit is updated in Fenergo, that resolution becomes the latest, even if the screening results task has not been completed. This provides clarity on the current status of each hit.
• Multiple Screening Processes: In journeys with multiple screening processes, the matching hits will reflect the resolution from the most recent screening process.
• Configuration Sets: Screening resolutions are not reused across different configuration sets. Each set maintains its own set of resolutions.

Hit Identification

EntityUniqueID: This screening property serves as the unique identifier (match ID) to link IDs across different screening batches. It ensures consistency and traceability of entities throughout the screening process.

Important Considerations

• For custom providers, EntityUniqueID must be populated and unique for each screening hit to enable the proper functioning of this feature.
• This feature does not apply to WCO. To update a resolution for a WCO hit, the entity must be taken through a new screening journey (e.g., a maintenance journey) and the decision updated.

Performance Guidelines and Limitations

• API Payload Response Limit: There is a 6MB limit on the API payload response returned from the Screening Providers.

• Limits on Screening Results: Due to the payload response limit, there are restrictions on the number of Screening Results that can be consumed into Fenergo SaaS. The number of results that can be supported will depend on the size, measured in number of characters, of individual hits within the results. In order to manage the response size, users can provide additional Secondary Identifier data to the provider to refine the search results, or apply Scoping Rules to filter and reduce the number of entities being screened.

• Impact of Individual Hit Size (in Characters): The number of entities or hits that can be supported does not have a precise limit. It will vary depending on the size of individual hits. Some hits may have extensive Biography/Profile data spanning multiple pages, while others may have only a single sentence. This size difference significantly affects the number of hits that can be supported.

• Screening Entity Selection Task Limit: There is a maximum of 1000 entities limit on the entities that are displayed in the Screening Entity Selection Task taking into account the main entity plus the related parties.

• Request Screening Task Limit: There is a maximum of 1000 entities limit on the Request Screening task taking into account the main entity plus the related parties.

• Tested Scenarios and Results: The system's capabilities have been evaluated through various test scenarios. The obtained results provide an overview of the supported functionalities based on these tests::

  Entity	No Matches	Size	No of Entities Supported
  Entity A	4	9,050	700
  Entity B	19	57,480	275
  Entity C	20	113,000	150
  Entity D	36	126,576	225
  Entity E	22	395,490	25
  Entity F	40	434,460	30

  Note: The number of entities supported refers to the number of entities of that size that can be supported in a single batch.

Ensure that you consider these performance testing results and associated limits when utilizing the Screening service.

Reporting

Screening data can be reported on using the Advanced Reporting feature; for full details on available tables refer to the Advanced Reporting User Guide.