ISDA Ongoing Update and Match ID Removal events are now queued automatically when S&P updates arrive while a journey is open with unverified data. Queued journeys trigger once the current journey closes — no manual intervention required.

Journeys can now be configured to require re-screening when screening results have aged past a set validity period. The new Verify Screening Period task checks every screening process it governs against the validity period configured on the relevant Configuration Set(s), and blocks the journey with a checkpoint if any result has expired.

At the checkpoint, users can go back and refresh any governed screening stage — not only the one that expired — or continue without rescreening. Going back is recorded to the audit trail like any other reopen; continuing without rescreening is reflected in the task's completion record instead. Verify Screening Period is available for both Screening V1 tasks and the ODS: Screening Resolution & Materiality (v2) task.

When configuring mTLS for an outbound endpoint, you can now choose how your server's certificate is validated. Keep pinning your server's leaf certificate (the default), or upload your certificate authority's self-signed root and any intermediates so that leaf certificate renewals no longer require a configuration update. The same options apply to the OAuth 2.0 token endpoint.

KYC and compliance analysts can now select all screening hits visible on the current page and bulk-resolve them in a single action — applying a status, reason, and comment to every selected hit at once.

Ongoing Screening alerts from World-Check One can now be routed by Configuration Set. Each Configuration Set can be individually enabled for Ongoing Screening and mapped to its own Journey Schema for Individual, Company, and Other entities, so alerts from different screening groups launch the correct review journey.

Where an entity is screened On Demand under more than one Configuration Set, Ongoing Screening results are now processed and routed separately for each set, rather than a single Journey Schema handling every alert.

It is now possible to navigate from the Entity Profile Page of an Investment Account to the related entity via a 'Related Entity' tile on the Investment Account Entity Profile Page.

Agency Bulk Upload no longer requires a Managed Relationship file. Where customers don't hold Managed Relationship data, the Managed Relationship data type can be de-selected on the Agency ETL task, and the system will find or create the Managed Relationship between the Investment Manager and each Underlying Principal during Load. A new Autoname MRs setting gives those Managed Relationships a meaningful name automatically. This is available now on non-live tenants and will be enabled on live tenants from 5 October 2026.

ETL Agency Migration can now automatically name new Managed Relationships that are created without a name, using the format "MR - [Investment Manager Legal Entity Name] - [Underlying Principal Legal Entity Name]". Managed Relationships created by the system no longer display as a generic "Managed Relationship", making them easy to tell apart where an Underlying Principal has several. This is available now on non-live tenants and will be enabled on live tenants from 5 October 2026.

ETL Agency Migration can now automatically launch Fenergo journeys for migrated Investment Managers and Underlying Principals once they have loaded, so that follow-up activity such as onboarding, Risk Assessment, Screening or Due Diligence can begin without launching each journey manually. Journey Launch is available now on non-live tenants and will be enabled on live tenants from 2 October 2026.

Note: this feature is currently available as a Beta and can be enabled on request. Clients interested in this feature should contact their Fenergo representative.

Administrators can now update the email address of a user who signs in via Single Sign-On (SSO) directly from the User Details page, keeping Fenergo in sync whenever a user's email changes on their organisation's side. The change is provisional until the user signs in again via SSO with the new address, which confirms it automatically; a pending change can also be cancelled before that happens, reverting the user back to their original email.