29 posts tagged with "Screening"

Screening v2 Classification Data fields could previously only be configured against the Client, and once configured they always rendered regardless of the case's policy attributes. This release adds trigger conditions, so a Classification Data field can be shown or hidden based on Policy field values on the main entity of the journey or the entity of the match, and a Target Entity setting so a field can be configured specifically for the Client or a Related Party.

The left-hand Legal entities list in the ODS: Screening Resolution & Materiality task now shows each entity's screening status at a glance and can be filtered and searched, so reviewers can quickly find and focus on the entities that need attention — without opening each one. This is particularly useful on large hierarchies and in Maker/Checker escalation reviews.

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.