When the Default Investment Account Name toggle is enabled, the Investment Account name is now automatically generated to include the linked Fund Product type, in addition to the Entity name and Fund name.

The updated naming formats are:

• No Fund linked: EntityName_Account
• Fund linked, no Product: EntityName_FundName_Account
• Fund and Product linked: EntityName_FundName_ProductType_Account

The name updates dynamically as Fund Product linkages are added or changed. If the generated name exceeds the configured character limit, it is truncated from the end. No new toggles or permissions are required - this behaviour is governed entirely by the existing Default Investment Account Name toggle. The tooltip text for this toggle has also been updated to reflect the new logic.

The recently released Document Metadata Policy Trigger Condition feature has been removed from the platform. Following release, we identified an issue that affects environments with high volumes of documents, and in order to protect the platform stability for all clients we have made the decision to remove this feature at this time while we work on a more robust solution. If you have already begun configuring this feature, please reach out to your Fenergo representitive who will be happy to advise on alternative approaches in the interim. We apologise for any disruption this may cause.

We've made some minor adjustments to the way that data is saved and validated within the Manage Products task. These changes are expected to improve performance by reducing the volume of changes that are saved at one time.

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.

This feature is an extension of the current V2 linked lookups in the policy domain, added in the product domain. The update shifts the configuration approach from the parent field to the child field. It enables a single parent field to support multiple child fields, each with independant filtering logic, improving flexibility and supporting one to many relationships.

To maintain compatibility, the existing Linked Lookup fields remain as-is, now labelled with a 'Legacy' prefix. This ensures that existing field configuration persists without intervention.

This feature allows you to manage your own client ID’s, secrets and certificates for API access in the Fenergo application via configuration tooling. This allows for granular control over API access and integration points. It can be used to solve for a wide variety of use cases across multiple integrations. This self-service feature means you no longer need to raise service requests for the creation of API clients.

IMPORTANT This feature is enabled in all tenants and will require adoption from all clients. From the end of May 2026 our SaaS request process for creating API Client IDs on your behalf will cease and you will be responsible for creation and maintenance going forward.

This feature provides the ability to configure rules that drive the signature type assigned to recipients in the eSignature task based on primary entity data.

This update supports key business scenarios such as data corrections and remediation loads, where existing lookup values must be intentionally removed.

• ETL Map Lookups step accepts NULL as a valid input for lookup fields.
• Users can proceed to Preview and Load when NULL is provided.
• Existing lookup values are cleared in the target record when NULL is processed.
• Behaviour is now consistent across lookup and non-lookup field types in ETL migrations.

This release introduces a new configuration option for Product Scoping Rules of type Connected Journey, allowing you to control whether matching products are grouped into a single connected journey or launched into separate connected journeys.

This release introduces a new Product Journey Checkpoint task type for onboarding journeys that launch multiple product-specific connected journeys in parallel. The checkpoint acts as a synchronisation point in the parent journey, ensuring product-level work is finalised before the parent journey proceeds to subsequent steps (for example, client-level verification and activation).

This release enables you to:

• Add a Product Journey Checkpoint task to a Journey Schema in Journey Builder.
• Pause a parent journey until all connected product journeys launched from the same parent are finalised.
• View the set of launched connected journeys directly within the checkpoint task and navigate to them (subject to existing access permissions).

Configuration rules and validation​

• A Journey Schema can contain only one Product Journey Launchpad task.
• A Product Journey Checkpoint task can be added only to a Journey Schema that contains a Product Journey Launchpad task.
• The checkpoint must be placed in a sequential stage and process that occurs after the stage containing the Launchpad task.
• If a user attempts to save a Journey Schema that violates these placement rules, the save fails and an error toast is displayed:
  • Product Journey Checkpoint must be placed in a sequential stage and process that comes after the Product Journey Launchpad task
  • The invalid journey elements are highlighted in red.

Runtime behaviour​

When the Product Journey Checkpoint task becomes active, it identifies all connected journeys launched by the Product Journey Launchpad task from the same parent journey and displays them in a table with the following columns:

• Journey (the Product Scoping Rule name that triggered the connected journey)
• Name (the connected journey instance name; hyperlink to open, subject to permissions)
• Journey Status
• Application Status
• Started

Completion logic​

• The Complete button is disabled by default.
• The Complete button is enabled only when all listed connected journeys have a Journey Status of Complete or Cancelled.