We have introduced a number of usability enhancements to the Alert Dashboard to improve analyst workflow and efficiency:

• Activity Log Sorting: Sorting functionality has been added to the Activity Log.
• Alert Assessment Initiation: Users can manually trigger an alert journey.
• Alert Grid Configurability: Users can customise the columns displayed on the Alert Dashboard. Documented in the Alert Visibility section.
• Alert Source Column: Alert Source is now available in Alert grids.
• Alert Status in Alert Details: Alert status is now visible within the Alert Details view.
• Closed Alert Status Visibility: Status is now displayed for closed alerts.
• Copy to Clipboard (External ID): A copy icon has been added to External ID fields for ease of use.
• Entity ID in RHD: Entity ID is now displayed in the Entity Right Hand Drawer, with a copy-to-clipboard option.
• Frozen Columns: Key columns, including selection and row actions, are fixed to improve navigation across wide datasets.
• Hover Row Actions: Row-level actions are now available on hover for quicker interaction.
• Improved RHD Behaviour: The Right Hand Drawer now pushes content rather than overlaying it.
• Previous Assessments Relocation: Previous assessments have been repositioned for improved usability.
• Search by External ID (Alerted Transactions Grid): Users can search by External ID within the Alerted Transactions grid.
• Search by External ID (Entity Transactions Grid): Users can search by External ID within the transaction grid on the entity profile page.
• Sending and Receiving Partner Columns: Sending Partner and Receiving Partner are now available as columns within transaction grids.
• Transactions Grid Filtering: Users can filter transactions within the transaction grid to refine results.

These updates provide greater flexibility and streamline interaction with alert data across different investigation scenarios.

Entity Whitelisting allows an entity to be exempt from alert investigation for a specific counterparty and a specific rule, for a defined period. While the whitelisting is active, future alerts that match the same rule, entity, and counterparty are treated as whitelisted and do not need to be assessed in the same way.

Whitelists can be created as:

• Manual Whitelists which are created from the Alerts Dashboard.
• Whitelists from an alerted transaction within an alert.

The audit trail of a Whitelist can be found on the main entity profile in the audit drawer.

Policy fields that use conditional logic driven by values derived from core customer fields, such as Age from Date of Birth may feed directly into the entity risk assessment and may also be used in business rules. Instead of refreshing these values in the context of a journey, these fields can be updated as part of the behavioural risk re-evaluation flow. These fields will be refreshed before any risk processing runs, so the latest values are used by the risk model and downstream rule logic.

The TM Rule Execution Status Endpoint lets you monitor the progress and outcome of a rule execution run in real time — giving you a complete, per-rule breakdown of status, alerts, and timing for any execution identified by its execution_id.

The documentation for the POST /event/transaction/v3 endpoint has been expanded with detailed validation behaviour and field-level guidance.

The TM Rule Schedule Endpoint gives you visibility into your rules' execution schedule — useful for understanding upcoming rule runs and verifying schedule changes after configuration updates.

The TM Rules Rerun API lets you re-execute specific scheduled rules for a past date to support controlled reprocessing—useful for remediation, backfills, and operational corrections—without needing manual technical intervention.

These update are part of the iterative customer experience enhancements being delivered within the Transaction Monitoring (TM) case management module in Fenergo. The primary objective of these enhancements is to consolidate all information required for an analyst/ investigator to assess an alert efficiently, accurately and quickly. The case management view has been designed to provide optimal user experience, ensuring the most relevant information is readily available within the alert and presented with suitable context to determine whether the activity is suspicious.

As a result, analysts can now easily access and navigate between Alert, Entity, and Transaction information, while maintaining full visibility of the ongoing investigation. This seamless context switching reduces friction, improves efficiency, and supports more informed and consistent alert decisioning by keeping all relevant alert, entity, and transaction information in a single, unified view, removing unnecessary navigation.

• Addition of the Right-Hand drawer with three different context Entity, Alert and Transaction
• Addition on information popover for Alerts and Transaction, allowing users to see a summary of either and the ability to access the RHD
• Alert page enhancements, addition of Entity details, reorganisation of page, enhanced view
• Update of EPP Alerts grid
• Improvement of Alert Assessment flow, using the RHD
• Addition of Counterparty names to Alert
• Addition of Transaction Summary to Transactions grid
• Addition progress bar to Alert Assessment
• Addition and extension of Alert Activity to RHD
• Add Entity Risk to Alert views

Manual Alerts allow authorised users to create Transaction Monitoring (TM) alerts directly from the Fenergo user interface without relying on the detection engine or external API integrations. This capability supports operational and investigative scenarios where an analyst determines that an alert should be raised.

Manual Alerts can be created as:

• Transactional Manual Alerts – linked to one or more selected transactions.
• Non-Transactional Manual Alerts – created at entity level without associated transactions.

Once created, alerts follow the standard Alert Assessment workflow.

Behavioural Risk solution in Fenergo has been extended, to cater for multiple risk models. This feature will improve and extend the behavioral risk capabilities by adding the following:

• Allow for the creation of multiple instances of the Risk Configuration in the Transaction Monitoring domain
• Each separate instance of the configuration will have configurable scoping conditions
• The data source type of ‘Current Entity’ can be used in the scoping conditions
• Each separate instance can be uniquely named