Rules Manager now supports granular permissions for detection rules, allowing access to be configured by action. Permissions can be assigned to users or teams in Security Configuration, making it possible to separate rule authoring from publishing.

Key enhancements include:

• New Rule Manager permissions for viewing lists, viewing rule details, editing drafts, running backtests, viewing backtest results, publishing, archiving, and importing/exporting draft rules
• A Submit for approval action for draft detection rules that are ready to be reviewed
• A publish approval flow where users with Rule Publish permission can Approve or Reject a submitted rule
• Rejection notes recorded in the rule activity trail, providing context for why a publish request was rejected
• Approval status surfaced on the draft rules list, with the ability to identify rules awaiting approval or recently rejected

These updates provide more control over who can perform specific Rule Manager actions and support maker-checker workflows for publishing detection rules.

User Guide Reference: [TM User Guide > Rules Manager](/user-guides/fenergo-transaction-monitoring/the-business-rule-manager

Reference lists used in rules now support multiple columns on a single master list. Instead of maintaining several near-duplicate lists (one per indicator), maintain one master list with a column for each membership indicator and pick the column to evaluate at the rule level.

Key enhancements include:

• A single master list with multiple membership-indicator columns (e.g. EEA Country, FATF Increased Monitoring, EU AML High-Risk Third Country on one country list)
• A new Column selector in the rule builder when using in reference list / not in reference list — leave empty to match the full value set
• Case-insensitive membership values — 1, Y, Yes, True, On count as members; empty, 0, N, No, False, Off do not
• Automatic rule updates for live rules when the underlying list is republished including audit logs.
• Publish-time validation that flags rules whose selected column has been removed from the latest list version, with the change recorded in the rule activity tab

The Transaction Monitoring Observability API now supports on-demand Transactions Data Export, enabling users to request and retrieve a report of transaction IDs ingested on a specific date. This provides a structured mechanism to reconcile which transactions have been received by Transaction Monitoring for a given day.

Exports return transaction identifiers (modification IDs) only for the requested date.

Exports are generated asynchronously:

1. Trigger a report for a chosen date and receive a trigger_id
2. Use the trigger_id to retrieve the report once it is ready

Note: This export is not a substitute for alert data sources.

Backtesting now uses schedule-driven activations to simulate rule execution more accurately. Instead of replaying every day in a selected date range, the system calculates when the rule would have executed based on its configured schedule (daily, weekly, or monthly).

Key enhancements include:

• Calendar highlights showing actual activation days

• A detailed list of activation timestamps used in the simulation

• Enforcement of activation limits:

  • Daily: up to 31 activations
  • Weekly: up to 12 activations
  • Monthly: up to 12 activations

• Date range validation based on activation count, with clear feedback if limits are exceeded

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.