Product Updates

Portal administrators can now control field-level visibility in the Fenergo Portal using Access Layers. This enhancement ensures that sensitive fields are only visible to the correct Portal users: User Guide Reference: Configuring the Fenergo Portal > Portal Roles Configuration > Access Layers

Portal users can now benefit from an enhanced Documents V2 experience, featuring improved visibility of requirements, clear card-based layout and guidance, and a simplified view of outstanding documents. This all leads to a more intuitive and streamlined document submission experience. User Guide Reference: Documents UX Improvements > Using the Fenergo Portal

Gives users the ability to remove multiple associated entities from the Related Party hierarchy in a single action, with permission-based access, confirmation and progress modals, and changes finalised after the Verify Related Party Associations V2 task. User Guide Reference: Using Related Party Management User Guide > Related Party Management

New approach to rate limiting Ingress Events by complexity. Developer Hub: Rate Limiting Events

ISDA Initial Data Sourcing task enhancements including individual linking of datasets, support for extra data sets (include EMIR Legacy, EMIR Refit (UK and EU), and SBS) and MR Support User Guide Reference: ISDA Amend

Trigger the execution of scheduled rules for a specific date POST /api/rules/execute

Updated response to include entity type. Affected Endpoints​ POST /entitydataquery/api/v2/entity/names

ISDA Initial Data Sourcing task enhancements including individual linking of datasets, support for extra data sets (include EMIR Legacy, EMIR Refit (UK and EU), and SBS) and MR Support User Guide Reference: ISDA Amend

This endpoint is marked as obsolete but will continue to be supported with no planned termination date. However, its usage is not recommended as it does not support full field-level validation. PUT /api/entity/{entityId}/draft/{id} Copy EntityDraft Command v2 endpoints to v3.

Update BatchExternalIds to use their own model (BatchExternalId instead of ExternalId), as it does not make sense for a BatchExternalId to have EntityAliasId since BatchExternalId is specifically related to the batch, not any of its entities. This should not affect any clients as Alias Screening has not been enabled yet. Affected Endpoints​ POST /screeningreceptor/api/receptor (ScreenResponseDto, OngoingScreeningGetResultsResponseDto) POST /{anyScreeningAdapter}/api/resolvematches (ResolveMatchesRequestDto) GET /screeningquery/api/batch/{id}, GET /screeningquery/api/batch/journey/{journeyId}, GET /screeningquery/api/batch/journey/{journeyId}/process/{processId} (BatchDto)

This feature introduces the ability to connect multiple Fenergo tenants to a single Salesforce instance. User Guide Reference: Salesforce User Guide > Salesforce to Fenergo multitenant

Clients can now customise the Portal’s look and feel using the new Custom CSS Styling feature. This enables rapid, branded, visual updates and customisation across Standard and High Contrast modes. User Guide Reference: Custom CSS > Configuring Custom CSS Styling in the Portal

This enhancement introduces the ability to configure and display custom metadata fields as additional columns within the Linked Documents and Matching Documents grids. This provides greater visibility of document-level data directly in the UI, reducing the need for users to open individual document records. Users can configure up to two text-based metadata fields (excluding rich text) via the Document Metadata Configuration screen. Once enabled, the selected fields will appear in the relevant document grids, with values truncated for readability and full text available via tooltip on hover. This enhancement applies to document requirements using the Document V2 framework. User Guide Reference: Document Management -> Configurable Metadata Columns in Document Requirements Grid

Added fields to support implementation of Alias Screening. There are no breaking changes here, so adapter implementations will continue to work as normal without the need of making any change. Affected Endpoints​ POST /screeningreceptor/api/receptor Added entityAliasId to ExternalIdDto. If not using AliasScreening, entityAliasId should be always set to PrimaryName (null will default to PrimaryName). Renamed AliasDto to MatchDataAliasDto for aliasesList in MatchDataDto (this is not considered a breaking change as only the name of the model was changed). Added externalIds and entityAliasIds to MatchDataDto and set externalId as obsolete, since it will be removed in the future. If not using AliasScreening, entityAliasId should be always set to PrimaryName (null will default to PrimaryName). POST /{anyScreeningAdapter}/api/screen Added entityAliases to ScreenRequestEntityDto. Only needed for providers that want to support AliasScreening. Added entityAliases to OverriddenBatchEntityDto. Only needed for providers that want to support AliasScreening. POST /{anyScreeningAdapter}/api/resolvematches Added entityAliasId to ExternalIdDto (batchExternalIds and entities.externalIds). If not using AliasScreening, entityAliasId should be always set to PrimaryName (null will default to PrimaryName). Added entityAliasIds to ResolveMatchesRequestEntityDto. Only needed for providers that want to support AliasScreening. Added externalIds and entityAliasIds to ResolveMatchesRequestMatchDataDto and set externalId as obsolete, since it will be removed in the future. If not using AliasScreening, entityAliasId should be always set to PrimaryName (null will default to PrimaryName). POST /{anyScreeningAdapter}/api/ongoingscreening Added entityAliasesForEnable to OngoingScreeningRequestDto. Only needed for providers that want to support AliasScreening. POST /{anyScreeningAdapter}/api/ongoingscreeningupdate Added entityAliases to OngoingScreeningUpdateRequestDto. Only needed for providers that want to support AliasScreening. GET /screeningquery/api/batch/{id}, GET /screeningquery/api/batch/journey/{journeyId}, GET /screeningquery/api/batch/journey/{journeyId}/process/{processId} Added entityAliases to BatchEntitySearchDto. Added entityAliasId to ExternalIdDto. GET /screeningquery/api/batch/{batchId}/entity, GET /screeningquery/api/batch/{batchId}/entity/{entityId} Added entityAliases to BatchEntityDto. Added entityAliasId to ExternalIdDto. GET /screeningquery/api/batch/{batchId}/entity/{entityId}/match, GET /screeningquery/api/batch/{batchId}/entity/{entityId}/match/{matchId} Added entityAliasIds to MatchDto. Added externalIds to MatchDataDto. Renamed AliasDto to MatchDataAliasDto for aliasesList in MatchDataDto (this is not considered a breaking change as only the name of the model was changed). GET /screeningquery/api/entity/{entityId}, POST /screeningquery/api/entity/getentitieslist Added entityAliases to ScreeningEntityDto.

This feature introduces Client Offboarding and Client Reonboarding functionality to Salesforce, matching the capabilities in FenX. It includes journey types, modal updates, jurisdiction selection logic, and system tasks needed to facilitate full and partial client lifecycle transitions. User Guide Reference: Salesforce User Guide > CLient Offboarding and Reonboarding

Extend configuration to support capturing a list of data keys for document expiry data fields Affected Endpoints​ PUT /documentmanagementcommand/api/configuration GET /documentmanagementcommand/api/configuration

A new secondary identifier field is now available for LexisNexis and any custom screening provider: Passport Number. This must be enabled in the screening provider's Secondary Identifier Configuration in order to use. For LexisNexis Ongoing Screening (OGS), the Batch Formats configured in Bridger must be updated to include Passport Number for it to be sent and used in OGS. The updated Batch Format files can be downloaded from the User Guide. User Guide Reference: Configuring LexisNexis

Added PassportNumber to SearchCriteria in batch and to SecondaryIdentifiers in configuration. Right now it's only supported for LexisNexis and any custom providers that want to implement it. Affected Endpoints​ POST /screeningcommand/api/batch POST /screeningcommand/api/entity PUT /screeningcommand/api/entity/{entityId} POST /screeningcommand/api/v2/configuration/provider PATCH /screeningcommand/api/v2/configuration/provider/{providerId} GET /screeningquery/api/batch/{id} GET /screeningquery/api/batch/journey/{journeyId} GET /screeningquery/api/batch/journey/{journeyId}/process/{processId} GET /screeningquery/api/batch/{batchId}/entity GET /screeningquery/api/batch/{batchId}/entity/{entityId} GET /screeningquery/api/entity/{entityId} POST /screeningquery/api/entity/getentitieslist GET /screeningquery/api/v3/configuration GET /screeningquery/api/v3/configuration/provider/{providerId} POST /{anyScreeningAdapter}/api/screen

A new configuration setting has been added to allow administrators to require users to enter a comment when waiving a document. This setting can be enabled from the Document Requirement Metadata configuration screen. When turned on, users will not be able to complete a waiver without providing a comment. The configuration applies to all waiver tasks going forward and supports improved compliance tracking. User Guide Reference: Document Management -> Mandatory Comments on Document Waiving

A new configuration option has been added to allow tenant-level control over whether users are required to provide comments when cancelling a journey. A user with the journey edit permissions can now enable or disable the "Require comments when cancelling a journey" setting from the journey configuration panel. When enabled, users must enter a comment before cancelling a journey. The setting is applied automatically across all in-flight journeys, with no need for manual saving. User Guide Reference: Configuring Journeys -> Mandatory Comment on Journey Cancellation

The Advanced Search Dashboard introduces a new dashboard type in the Standard Portal enabling Portal users to search for Company and Individual entities using configurable filters. It provides a table-based search experience for investor-related data. User Guide Reference: Using the Fenergo Portal > Advanced Search Dashboard

This feature removes the validation that prevented users from adding a Risk Assessment task (of any type) to a process within a stage that was configured with process completion order set to 'In any order'. This allows you to complete jurisdictional KYC requirements within the same stage, improving overall onboarding times by better supporting parallel work effort. User Guide Reference: Configuring Risk Functionality -> Risk Configuration in Journey Builder

This feature introduces the ability to upload documents via the Entity Profile Page in the Portal, meaning users can now upload a document without launching a journey. User Guide Reference: Using the Fenergo Portal > Upload Documents: Entity Profile Page

An update has been applied so the Related Party Scoping Rules can now be located under the Journey management menu option. User Guide Reference: Related Party Management->Related Party Adapted Experience

Alerts Integrated Workflow - new alerts workflow using Fenergo Alert Object, new Alerts Dashbaord with associated alerts permissions set. Configurable Alert journey. Transaction and alerts view from Entity Profile. Alert Dashboard​ New Alert dashboard available for users with the Alert Access permission. Here users can see "All Alerts" or "My Alerts". Actions on this dashboard include Alert Assignment or Unassignment, Alert group creation and bulk operations. This dashboard shows the relevant details for the alert, including Alert Id,status, Main Entity, Business rule,Created Date, Assignee, Previous Assessment, no. of transactions and Total Monitoring Amount. Alert Assessment Journey​ New Journey type which can be configured with Alert Assessment tasks which will allow permissioned users to assess transactions contained in an alert. The new journey should be configured using relevant Alert Scoping conditions and Alert relevant event triggers. Alert Assessment Task​ New Alert Assessment task, once an Alert is assigned to the relevant team member they can assess the alert from this task. This task will show an Alert details summary and the transactions that are contained in this alert. Transactions can be assessed using the configurable AlertsAssessmentCategory/AlertsAssessmentOutcome lookup. Transactions details can be access from the transaction id link. Assessment comments and documents can be added, assessment can be submitted. Entity Transactions in CLM​ Transactions are available from the Entity Profile Page with the correct "Entity Profile Transaction View" permission. This will include all transactions for an entity. Entity Alerts​ Alerts are available from the Entity Profile Page. Entity Whitelisting​ Whitelisting a combination of Entity, counterparty and business rule for a set period of time, an alert will be trigger but flagged with status Whitelisted. An assessment journey will not be triggered for these as investigation is not required. Event Ingress, external Alerts​ Alerts with transactions can be triggered from the API using event ingress.