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.

This feature introduces a consistent Unlink action for removing linked relationships from an investment account without deleting the underlying records. Users can now unlink a verified bank account relationship from an investment account. The Unlink icon and confirmation modals are also standardised across bank accounts, funds, and related parties to clearly indicate that only the link is removed.

Adding to the recent release of ETL Post Processing, you can now apply Product Access Layers during ETL migrations, ensuring migrated data aligns with access and security standards.

This capability can be enabled per ETL project using Post Load Actions. Once ETL Load completes, the recalculations run asynchronously and apply to all Products included in the migration.

• Dynamic Product Access Layers: Re-evaluates and applies rule-based access control for Products. Where Products satisfy a Dyanmic Access Layer rule with 'Product' data type, the associated Access Layers will be assigned. If no rules are met by a product or if the toggle is disabled in the ETL project, then default access layers (Enterprise and Global) will be applied.