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.

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:

Until now, every client's screening workflow required a materiality assessment, with no way to turn this off for a client whose process does not need it.

This release introduces a Materiality Assessment entitlement that can be switched off for a client. When it is, the materiality action, the Material/Immaterial/Escalated status chips and Materiality filter, the reassessment warning, and the requirement to complete materiality before finishing the task are no longer shown, along with the Materiality column on the Screening Assessment Outcomes tab. Escalate is unaffected and continues to work as before. This is managed by Fenergo Support or Product; there is no client-facing configuration screen.

The ODS: Screening Resolution & Materiality results table can now show a Classification data column, so reviewers can see a hit's captured Classification Data without opening the Match Resolution popup.

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.

ETL Agency Migration is a new and separate capability, leveraging ETL to migrate agency objects. It exists for a single purpose: to build the Agency Data Model. It migrates Investment Managers, Underlying Principals, Managed Relationships and Managed Products, and constructs the relationships between them automatically.

ETL Agency Migration brings agency migration into the same self-service, preview-and-validate experience clients already use for standard ETL. It complements standard ETL rather than replacing it — where an Investment Manager or Underlying Principal is also a client, its full client record is still migrated through a standard ETL project.

Reviewers can now assess Bank Account and Investment Account information directly within the Review & Approvals Task, alongside existing entity, related party, product, and document data. Bank Accounts display in their own list with New/Changed indicators and a field-level Details view; Investment Accounts display with drill-in access to Details, Document Requirements, Funds, Bank Accounts, and Related Parties.

Visibility of individual accounts is enforced by the reviewer's Entity and Search access layers, and existing Review & Approvals commenting, permissions, and approval decision behaviour apply consistently across both account types.