The Journey Audit Drawer now includes a Journey Data Changes tab, showing the audit record for journey level data captured in this specific journey. Journey level data is captured by data tasks in the journey rather than against the entity record, and is typically used for gathering field inputs that will drive other journey behaviours or capturing data that is only pertinent to each specific journey instance.

Previously, changes to journey level data were not part of the audit record and were not visible to reviewers. The new 'Journey Data Changes' tab lists each journey level data field that has been populated within the journey along with its current value, who last updated it and when, and expanding a field reveals its full history of changes within that journey. It follows the same layout as the 'Entity Data Changes' and 'Product Data Changes' tabs, and requires no additional permissions to view.

User Guide Reference: Audit in Fenergo -> Journey Level Audit

Analysts can now have Screening Classification Data captured directly at the point an Ongoing Screening hit is confirmed as a match, rather than waiting until the downstream On-Demand Screening task. Once captured, that classification is reused automatically across every related On-Demand Screening task the confirmed match triggers.

The related party duplicate search within journeys has been enhanced to support searching by data group fields such as Address Details and Tax Identifiers. Previously, users could only search using standard policy fields, requiring separate searches outside the journey to verify identity using critical identifiers. Configurators can now designate one or more data groups as part of the duplicate search scope on the Related Parties, Related Parties Data & Documents, and Hierarchy Capture task types in Journey Schema Builder. When configured, users will see additional input fields for those data groups in the search panel when adding a related party. Providing all mandatory data has been entered, users may search using only policy field values, only data group field values, or a combination of both. Matching entities are returned in the existing Potential Duplicates panel. This reduces the risk of duplicate related party creation, improves data integrity, and keeps users within the journey workflow throughout the onboarding process.

The Product Risk Assessment task now excludes products that are leaving a client relationship. Products with a lifecycle status of Offboarding or Offboarded are removed before the assessment begins, so that an entity's product risk reflects only the products it actively holds.

This is feature will affect how product risk is calculated and does not have a configurable opt-in mechanism. For tenants with the Product domain enabled, the change is available in non-live tenants from 26 August 2026 and will be enabled in all live tenants from 29 September 2026. To have it applied to your live tenant earlier, contact your Fenergo Client Partner.

The Product Related Party Checkpoint is a new system-managed task that blocks a parent journey from advancing until all Product RP child journeys launched by the Product Related Party Launchpad have reached a terminal state. This ensures that the Merge Product Related Party Drafts and Verify tasks only execute against fully completed due diligence data.

Administrators can now configure the Orbis integration to exclude indirect shareholder associations from returned ownership hierarchies. When enabled, shareholder associations without a direct ownership percentage are removed, providing a cleaner view of direct ownership structures.

The Orbis external data integration now returns inactive companies alongside active entities. KYC analysts can search for a company by name or identifier and receive a match from Orbis regardless of whether the entity's status is active or inactive.

Tenants with the Product domain enabled can now control which Product Categories appear in the Product Details modal on the Entity Profile Page, and the order in which they appear. Product is available as an Entity Type within Entity Profile Configuration, alongside the existing Legal Entity Types. Previously the modal displayed a fixed category order that could not be changed.

Previously, there was no way to reverse an entity's escalation once it had been raised during a Materiality Assessment — even after a corrected or superseding decision, the entity remained flagged as escalated indefinitely.

This release introduces automatic de-escalation. When you set a new materiality status on an assessment for an entity that is currently escalated, the escalation clears as part of that same action — there is no extra step, prompt, or new screen to interact with. Every de-escalation is recorded in the audit trail alongside the entity's other history.

This release introduces a new "Clear Value if Trigger Condition Not Met" toggle in the policy editor for entity and product level. When enabled on a data requirement, if all associated trigger conditions for a field are no longer satisfied, any previously saved value is automatically cleared at both the product or entity levels. This ensures that hidden fields no longer store an invalid value. The toggle is opt-in and defaults to off.

See user guide for the full configuration guide and behaviours to note with this new functionality: