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.

Administrators can now add, edit, and remove References, including type, description, and URL, for Data Group Domain Policy field-level entries. This brings the Data Group Domain Policy configuration in line with the References capability available across the wider Policy module.

KYRA:Screen now includes a configurable Screening Instructions page, giving compliance and configuration teams direct control over how the agent evaluates and resolves screening hits — without any code changes required.

This enhancement doesn't require any actions to enable — System Default Instructions are applied automatically. We strongly recommend reviewing them and amending or supplementing them with custom instructions specific to your organisation before your next screening run.

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.

The Entity Profile Audit Drawer now includes an "RP Associations" tab, showing the audit trail for standard Entity-to-Entity association records (Related Parties) — including additions, removals, and relationship type changes. This enhancement doesn't require any actions to enable.

ETL now supports the bulk deletion of existing association records using the new Delete Associations data type. Combined with the existing Associations data type, this also enables a net update to an association's relationship type in a single ETL project — deleting the old relationship and creating the new one in the same load.

Search Text Fields are now supported within Product Requirement Sets and linked Data Groups. Now, when configured within products, users can retrieve values from an external or (Flows simulated) data source via a Policy Custom Search Provider. This facilitates ensuring that a correct value is selected from a trusted source (for example email address or external identifiers).

The Matching Tab in the Investment Account Document Requirements workflow now also surfaces acceptable-type documents held at the related investor entity level, not just those linked to the investment account itself. Users can link a matched investor entity document directly to the investment account requirement without creating a duplicate document record.

Journey-level comments are now accessible from within a Task. Users can open the Comments shelf whilst working inside any Task in a Journey, without needing to navigate back to the Journey Hub.

User Guide Reference: Comments on LE and Journey

Custom External Adapters can now validate multiple Data Group fields in a single external call, and validation is enforced consistently across both the journey UI and API updates — ensuring data quality rules are applied whether fields are entered manually or submitted programmatically.