Recently active topics

Users can now configure Ongoing Monitoring for D&B for both the Client entity and its Related Parties using the D&B CMPBOL package. DunsId can now be used as a search parameter, and in the automated deduplication process of Related Parties. Data mapping files also added to the user guide. User Guide Reference: External Data Configuration User Guide: Ongoing Data Monitoring.

Users often assume that higher match scores directly represent higher risk, but in Fenergo, match scores indicate confidence in similarity between the screened entity and a potential match — not the inherent risk level. Each screening provider calculates these scores differently, and Fenergo interprets them as relative indicators of match strength.

Users often assume that clearing all matches automatically closes the associated screening case, but these two statuses serve distinct purposes. “Match Cleared” means an analyst has reviewed an individual screening hit and marked it as No Match or False Positive. This action resolves the specific match but does not complete the overall screening case. “Case Closed”, on the other hand, indicates that all matches within the screening batch have been reviewed, verified, and finalized. In Fenergo, a case may contain multiple matches — even if all are cleared, the case remains open until manually closed or until an Auto-Close configuration (such as Auto Close on All Cleared) completes the process.

Users may report that they cannot log in to the portal despite having active accounts and valid credentials. This typically occurs when there is an authentication configuration mismatch — most often related to Single Sign-On (SSO), identity provider (IDP) metadata, or certificate settings. In these cases, the issue is not with the user account itself but with the SSO integration or authentication parameters, such as expired tokens, outdated certificates, or incorrect redirect URIs registered in the portal’s authentication configuration.

Users often notice a sudden spike in false positives following a screening rules update or a change to provider configurations. This typically happens when the matching algorithms or fuzzy-match thresholds are adjusted to broader sensitivity settings. In Fenergo, updates to screening provider parameters or matching logic — such as changes to alias weighting, match confidence, or name field inclusion — can expand the range of potential matches returned for each entity, increasing the likelihood of false positives.

Users may notice that after a schema update or data model change, outbound integrations such as Webhooks or Integration Hub event flows stop delivering updates or begin omitting certain fields. This typically happens because outbound events depend on predefined schema definitions that do not automatically refresh when the underlying entity model is updated. As a result, once the schema changes, the configured webhook or integration may reference outdated field mappings or drop unmapped attributes until the schema is manually refreshed and re-published.

Users often expect that once an external system sends updated entity data to Fenergo, those changes should appear instantly in the UI or Journey context. However, Event Ingress and other integration workflows in Fenergo are asynchronous by design. When an event is received, the API returns a 202 Accepted response to confirm successful receipt — but the actual update occurs later, after the event has completed internal processing and passed validation. As a result, updates only become visible once the workflow finishes and a success notification is generated.

Users may notice situations where a Journey task appears as “Completed” in the UI, yet backend data updates or related operations are still pending. This discrepancy usually happens when the UI is showing a cached version of the task state that hasn’t been refreshed to reflect updates from the Journey Logic Engine. In many cases, the task may have been auto-completed by system rules in the background, or the user session may have loaded an outdated snapshot of the task list before the backend finished processing.

It can be confusing when tasks within a Journey execute in the wrong order or appear to be skipped altogether. This behaviour usually points to misconfigured dependencies or autocompletion conditions within the Journey schema. In Fenergo, task sequencing is controlled by the Journey Logic Engine, which determines execution order based on defined dependencies, autocompletion rules, and the validation status of preceding tasks.

Users may notice duplicate entries for the same Related Party when exporting data or running reports, even though the Related Party appears unique within the UI. This typically happens when multiple active associations reference the same Related Party entity, or when historical relationships were not properly deactivated during ETL merge processes. In some cases, duplicates can also result from reporting queries that join on non-unique fields such as entityName instead of unique identifiers like entityId or alternateId.

Users may notice that Related Party tasks show stale or incomplete details, even when the Related Party record or its associations have recently changed in another Journey, through an API update, or via an ETL process. This occurs because Related Party tasks in Fenergo display a snapshot of data captured at the moment the task was first opened. Any updates made outside the active Journey context are not automatically reflected until the task is refreshed or reinitialized.

It’s common to expect that once an association (for example, between a Client and a Related Party) is created in one Journey, it should automatically appear in other active Journeys. However, in Fenergo, each Journey instance operates on its own data snapshot, meaning changes made within one Journey remain local until they are verified and promoted. Associations created during a Journey stay in draft form until verified — only then do they replace the previously verified records and become globally visible across all other Journeys.

When working with complex Journeys that involve multiple entities — such as Clients, Products, and Related Parties — it can be difficult to understand how data updates flow between them. Fenergo provides built-in tracing and audit tools that let you see exactly where data changes originate, how they propagate across entities, and which system components (such as API calls, user actions, or Event Ingress events) triggered those updates.

It can be confusing when a Product that appears to have completed its Offboarding process suddenly changes back to “In Review” after another connected Journey starts. In Fenergo, this behaviour occurs because the Product’s state machine is automatically re-evaluated when a new Journey is triggered. If the Product still has open review steps or pending tasks, the platform may interpret it as incomplete and reset the state accordingly.

Users often assume that non-mandatory fields should never cause validation issues. However, in Fenergo Journeys, the validation engine evaluates all scoped fields, not just the mandatory ones, whenever Conditional Validation Rules or Dependent Rules are active. This means a field marked as “optional” can still participate in validation logic and generate warnings or blocking errors if it forms part of a conditional expression or dependency chain.

In some cases, users notice that after an Event Ingress is processed successfully, the Journey task does not reflect updated data in one or more entity fields. This can be confusing, the event appears to have triggered correctly, but the underlying entity (for example, Client or Product) remains unchanged. Understanding how Fenergo applies updates through Event Ingress and field scoping in Journeys can help diagnose why these updates are silently ignored or skipped.

This feature introduces a third and a fourth outreach email template to the Portal Configuration section. Configurators will now be able to select between four distinct email templates when creating an outreach snapshot. User Guide Reference: Configuring the Fenergo Portal Outreach Functionality > New Outreach Template

Includes pre-signed URLs in the response for batch transaction error file. GET /api/v1/batch-transactions/batch

Accounts can now be surfaced in the Conflict Resolution task. This will give users the ability to resolve conflicts on both investment accounts and bank accounts. User Guide Reference: Change Management Guide

Will from Fenergo walks through what the new Agency Bulk Upload capability can do and how it's configured. The new 'Agency ETL' task offers a new way to onboard large volumes of funds (Underlying Principals) and Products for an Investment Manager directly from an Agency Request journey. Instead of keying every fund and product through Add Parties to Request and Agency Request Details, users can now upload CSV files and map their contents to requirements to upload up to 1,000 Underlying Principals and 5,000 products per Agency Request journey.

Agency Bulk Upload introduces a new Agency ETL task within the Agency Request journey, allowing customers to onboard large volumes of Underlying Principals, Managed Relationships and Products for an Investment Manager using CSV files instead of manual UI entry. By embedding our Extract Transform Load (ETL) capabilities directly into Agency Requests, customers can process high-volume agency onboarding while still using the standard Agency data model, connected journeys and policy-driven validation. This release enables you to: Use Agency ETL task to bulk upload Underlying Principals, Managed Relationships and Products for high volume Agency Requests (up to 1,000 Underlying Principals and 5,000 Products per journey). Leverage powerful ETL capabilities, so you are not tied to a single file structure and can preview and validate your data before it's loaded: Upload CSV files per data type and Data Group. Filter data to target specific subsets of larger files. Map System Fields and Policy /