18 posts tagged with "Screening"

Screening V2 introduces two redesigned screening tasks across On Demand Screening (ODS) and Ongoing Screening (OGS). A new ODS: Screening Resolution & Materiality task combines hit resolution, hit classification, and materiality assessment — including, for the first time, materiality at Related Party (RP) level with one consistent outcome stored per RP. A new two-stage OGS: Screening Resolution & Client Selection task formalises the review of hits from periodic screening and drives the right downstream work per affected client.

This enhancement enables Ongoing Screening (OGS) to be configured per Configuration Set in LexisNexis, with two operational modes available via the new OGS Mode toggle:

• Default — every OGS-enrolled entity is screened against every OGS-enabled Configuration Set, with hits segregated into a separate journey per set (category-based segregation, single shared Accept List).
• Per Configuration Set — entities are subscribed to specific Configuration Set(s) and screened only by those (jurisdiction-based segregation, dedicated Accept List per set).

Each Configuration Set can be mapped to its own Journey Schema with its own SLAs, team assignment, and routing.

Clients using Automatic Offboarding with policies scoped by Related Products conditions will now see more consistent outcomes for their client entities during Ongoing Screening journeys. Policy evaluation calls made during Ongoing Screening journeys now include the Related Products data source, bringing them into line with all other journey types.

This means that policies referencing Related Products data are evaluated with the correct data available throughout the Ongoing Screening lifecycle, and automatic offboarding decisions accurately reflect whether scoping conditions are genuinely met.

Previously, unsubscribing related parties (RPs) from Ongoing Screening (OGS) during an offboarding journey was entirely manual. Users had to individually review and unsubscribe each RP, which at volumes of thousands or tens of thousands of offboardings, represented a significant burden of repetitive analyst work.

This release introduces automation support for the OGS: Unsubscribe from Ongoing Screening task, allowing the system to intelligently handle unsubscription for eligible entities and RPs without user intervention.

The Screening Results table now renders the LexisNexis source as a clickable hyperlink, allowing investigators to navigate directly to the corresponding alert in the LexisNexis (Bridger) portal without leaving Fen-X or manually copying the Alert ID.

Two new configuration types are now available for import via Configuration Exchange, extending the platform's ability to promote consistent configuration across tenant environments.

The Alert Confidence score from the GRID/RDC provider is now displayed within the Profile tab of a Grid screening result in Fen-X.

Screening resolutions can now be re-used when a screening process is reopened or when the same entity is screened again in a subsequent screening process (including in a different journey).

Where applicable, the most recently saved resolution for the same match is automatically populated to reduce repeat analyst dispositioning.

The Screening Results table has been enhanced for both On Demand Screening (ODS) and Ongoing Screening (OGS) through the introduction of a configurable table view. This enhancement allows users to prioritise and display the columns most relevant to their workflow, improving efficiency when reviewing and adjudicating screening hits.

Alias Name Screening has been extended to the LexisNexis integration, allowing entities to be screened using multiple names, such as aliases (AKA), former names (FKA), and native-script name variants—within a single screening submission. This capability, which is already available for WCO and custom screening providers, has now been enhanced to deliver the same multi-name screening experience for LexisNexis.

Screening results for each alias are consolidated under a single legal entity, with clear traceability of which name triggered each match. This enhancement reduces manual overhead, improves screening coverage, and increases transparency by removing the need to submit and reconcile multiple screening requests for the same entity.