Document Generation: Related Party Association Limit Increase
The Automated Document Generation task now supports up to 500 direct related party associations, up from the previous limit of 50.
The Automated Document Generation task now supports up to 500 direct related party associations, up from the previous limit of 50.
The Document Auto Link feature in Journey Builder enables documents stored on the Entity Profile Page to be automatically linked to matching document requirements when a task opens, eliminating the need for manual linking. Configurators can enable this via a toggle on the Documents V2, Data & Documents (Doc V2), Hierarchy Capture, and Related Party Data & Documents task types. When enabled, the system evaluates all available documents against the acceptable document types of each requirement during task pre-processing, after Document Persistence has run. See the user guide for exclusionary rules.
User Guide Reference: Document Management->Document Requirement Autolinking
We are introducing enhanced search capabilities for the Multi-Field External Search Provider as it exists for data groups. This builds upon the existing single-field search behaviour. In the first iteration, only a free-text search phrase was sent to the external adapter. This enhancement extends that capability so that additional fields from the relevant data group can also be selected as search criteria and included in the API request.
On the end user side within a journey, if data group fields are added to the search request then we will change the view in the data group. The search modal will show a two-tab layout: a Search tab presenting the search box alongside any configured data group fields, and a Details tab where the selected result is populated for review and saving. Where multiple providers are configured for the same data group, results are aggregated into a combined grid.
The Journey Audit Drawer now includes tabs to show audit records for Entity and Product data changes made in this specific journey. Alongside the existing journey lifecycle events under the Journey tab, reviewers can see entity field-level draft changes made within the journey on a new Entity Data Changes tab, and product field-level draft changes on a Product Data Changes tab (available where the Product domain is enabled in the tenant). An Only show edited fields toggle keeps the view focused on changes that matter, hiding fields that have only their initial draft state.
ETL Alerts enables the bulk migration of historical or externally generated alert records into Fenergo via CSV upload. Institutions transitioning from legacy Transaction Monitoring systems can use this capability to seed pre-existing alert data into the platform, ensuring a complete and uninterrupted alert history from day one.
ETL Financial Crime Reports (FCR) enables the migration of historical FCR records from legacy compliance systems into Fenergo via the ETL pipeline. Migrated records are created in Closed status with a source value of Migrated, preserving the original submission dates and external identifiers from the source system.
Policy V2 Edit Mode introduces full configuration capabilities, allowing users to create, edit, review, and publish Policy V2 configurations using workspaces and version-controlled drafts.
In August last year, we replaced the table component used in many areas of Fenergo, including data groups. The new component came with an integrated "+" button to add new entries to the table. For Data groups, Customer feedback told us we no longer needed the original named add buttons (same function), so we have now removed them leaving the standard "+" icon inside the table as the single Add control. This change applies to all editable Data Group contexts and does not affect existing functionality, configuration, permissions, or read-only views.
The Data Protection Dashboard Matches tab now supports bulk offboarding, allowing users to action multiple orphan entities in a single step. The Actioned tab has also been updated with a direct link to each entity's initiated offboarding journey.
Clients using Automatic Offboarding with policies scoped by Related Products conditions will now see more consistent outcomes for their client entities during Ongoing Screening journeys. Policy evaluation calls made during Ongoing Screening journeys now include the Related Products data source, bringing them into line with all other journey types.
This means that policies referencing Related Products data are evaluated with the correct data available throughout the Ongoing Screening lifecycle, and automatic offboarding decisions accurately reflect whether scoping conditions are genuinely met.