Join the Conversation

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.

I have added several requirements to a policy but they’re not appearing in my journey?

How can one hide related parties from a specific booking entity/jurisdiction when onboarding clients of multiple booking entities/jurisdictions. For example, I am using field-level access layers to hide all Mexico specific requirements from clients which are part of other jurisdictions. How can I hide the Mexico related parties from the other booking entities/jurisdictions?

When adding logic to Related-Party requirements, what should the ‘Source’ be for the trigger conditions?

I want to add details on Account for information in relation to the Investment itself. I don’t want them to appear against the Enrich profile for my Investor. What do I need to do in the policy to have this happen?