To allow for STP scenarios where clients wish to validate the Related Party Data & Document compliance and not make any changes to the hierarchy, an update has been made to Journey Builder validation to allow the configuration of the Related Party Data & Documents task without the Related Parties or Hierarchy Capture task in these STP journeys. Existing validation will apply where the task is configured alongside the Related Parties or Hierarchy Capture task in a journey.

User Guide Reference: Related Party Management->Related Party Adapted Experience

A small enhancement has been introduced to Audit so that the when a value is verified in a journey, the event now includes the Journey Id. Please note this is on a go forward basis.

ETL reconciliation reports now include document-level detail on every row, so any row can be traced back to the specific document it relates to. Each row records the Document Model ID, the unique identifier of the document in Fenergo, alongside the Document Path for uploaded documents or the URL for virtual documents.

The additional columns apply to Entity Documents, Product Documents, Entity Virtual Documents, and Product Virtual Documents reconciliation reports, removing the need to cross-reference the original migration bundle when investigating failed loads or post-migration queries.

ETL now automatically triggers journeys for migrated Individual and Company entities once a data load completes, allowing migrated entities to resume in-progress activities such as Risk Assessment, Screening, and Due Diligence without manual intervention.

Journey Launch is configured per entity type, with an optional filter to control which entities are in scope. A Journey Launch report is generated for each entity type, detailing the outcome for every evaluated entity to support reconciliation.

The Entity Profile Page Journeys tab now includes a Completed On column in the Journeys grid, displaying the date a journey was completed in DD MMM YYYY format. The column supports sorting, and a Date Completed field is displayed in the task status hover-over when a task is in a completed state. No additional permission configuration is required.

SLA calculations now support working day configuration. Previously, SLA deadlines were calculated using all calendar days, including weekends and non-working days. A new SLA Configuration screen has been added under Management → Journey, allowing configurators to select which days of the week are considered working days and set a Reference Timezone. When configured, SLA timers will only count business days — pausing on non-working days and resuming on the next available working day. For example, a 2-day SLA triggered on a Friday with Monday-to-Friday working days will result in a Tuesday deadline. The system default remains all seven days selected, preserving existing behaviour until a change is made. Two new permissions have been introduced: SLA Working Days Access (view) and SLA Working Days Edit (modify and save). No changes have been made to the existing journey, stage, or task-level SLA configuration.

User Guide Reference: Configuring Working Days for SLAs

With this release we have introduced a new control for dealing with ad-hoc reviews. This will ensure that updates to client profiles outside of the defined schedules will result in the correct updates to your review schaedules to stay aligned with internal policies and regulatory expectations.

As of now, clients that have been using our Journey Schedules feature to manage their reviews can transition over to the new functionality inside the Review Domain. This allows you to avail of the rich functionality including the Review Manager Dashboard, creation of reviews via ETL and more, see the review manager user guide for more information.

ETL now validates static Access Layers referenced in a migration file during the validation stage, before any entities are loaded. Any Access Layer that does not exist in the tenant configuration is flagged as a validation error, so the file can be corrected before the load proceeds.

Users can query access log data using the accesslogs table. This table provides a consolidated audit trail of user access across supported domains.

Access logs are captured for:

• Entity records
• Alerts
• Alerted Transactions (transactions contributing to an alert)
• Suspicious Activity Reports (SARs)