Summary cards above the grid show team-wide metrics on All Alerts (open alerts and average score, unassigned alerts, SLA status, and alerts closed in the period) and personal metrics on My Alerts (average time to assess, oldest open alert, SLA status, and entity risk profile). A charts panel presents the same data visually, with an SLA status breakdown on both tabs plus Assigned vs Unassigned on All Alerts and Risk profile on My Alerts. The Summary for dropdown filters the cards and charts to the last 7, 30 or 90 days, and both panels can be collapsed.

User Guide Reference: Transaction Monitoring -> Alerts Dashboard

Advanced Reporting now includes an aggregate scope field on the alerts table, plus two new tables — alert_rules and alert_rule_transaction_links — so the contributing rules and transactions behind an aggregated alert can be reported on individually or joined back to the alert.

The aggregated alert detail UI now shows rule-level and transaction-level whitelist indicators. When every transaction across every rule in the group is covered by an active whitelist entry, the alert automatically transitions to Whitelisted status.

User Guide Reference: Transaction Monitoring -> Advanced Reporting Tables

User Guide Reference: Transaction Monitoring -> Entity Whitelisting

Each alert shows an SLA status badge (In Progress, Approaching Due, Overdue, Paused, or Completed Overdue), with overdue time, committed allowance, and due date available on hover. SLA status is also filterable on the All Alerts and My Alerts views, with a Task SLA column on My Alerts for task-level status, and is included in Advanced Reporting to match the live dashboard and task view.

User Guide Reference: Transaction Monitoring -> Alert SLAs

Aggregated Alerts are identified by a dedicated icon in the Alerts Dashboard, with the Business Rule column displaying the Rule Group Name and the number of rules triggered. On the Aggregated Alert Assessment page, investigators can review the combined score, a full breakdown of triggered rules in the Business Rule Group section, and use a quick filter on the transaction grid to focus on the activity relevant to each individual rule.

User Guide Reference: Transaction Monitoring Investigations

User Guide Reference: ETL Extract Transform Load -> ETL Alerts

User Guide Reference: ETL Extract Transform Load -> ETL Financial Crime Reports

The dataset is exposed as a set of queryable tables. Each table is documented with its available fields and can be joined to build cross-entity or cross-alert views.

User Guide Reference: Transaction Monitoring -> Advanced Reporting

API Base URL Change​

TM API server URLs have moved from sentinels.cloud service endpoints to the standard Fenergo SaaS API gateway, following this pattern:

https://api.{region}.fenergox.com/tm/<service>

Replace {region} with your tenant's region identifier (e.g. emea1b). For the default EMEA tenant, the region segment can be omitted:

https://api.fenergox.com/tm/<service>

The <service> segment identifies the TM API being called (for example, realtime for the Transaction API or observability for the Observability API). The full URL for each operation is shown in the corresponding API specification page.

This aligns TM with the rest of the Fenergo platform — TM API traffic flows through the same infrastructure as CLM and other SaaS APIs, including the same network policies, rate limiting, and observability tooling.

Authentication​

Transaction Monitoring APIs use the OAuth 2.0 Client Credentials flow, the same as all other Fenergo SaaS APIs. Credentials already configured for CLM or another Fenergo SaaS API are fully compatible with TM — the same client_id, client_secret, and token endpoint apply across all services.

Authentication works by exchanging credentials once for a short-lived Bearer token, which is then passed in the Authorization header of every API request. Advanced options such as mTLS are also supported.

See Fenergo SaaS API Authentication for the full authentication reference, including mTLS endpoints and regional token URLs.

Docs​

• TM API Authentication

Transactions contained within alerts are reviewed at the point of deletion: if the counterparty is not a Fenergo entity, the transaction is removed from both CLM and TM; if the counterparty is an onboarded Fenergo entity, the transaction is retained. A periodic housekeeping process additionally clears any orphaned transactions that remain in the alerted transaction store without an associated alert.

User Guide Reference: Other CLM Functional Documentation (A-Z) -> Data Protection -> Deleting Data

The dashboard adapts to how your tenant ingests data. Real-time tenants see transaction ingestion metrics, while batch tenants see file and batch processing metrics. Both tenant types see rule execution metrics. Data shown on the dashboard is retained for 30 days.

This release enables you to:

• View transaction ingestion volume, success, failure and success rate over a selected time range (real-time tenants)
• View batch processing health, including batches processed, transactions processed, accepted and invalid, and the status of each batch (batch tenants)
• Track scheduled rule executions, including total executions, successes, failures and the number of unique rules run
• Select a custom reporting period using From and To date inputs
• Review daily breakdowns of ingestion, batch volume and rule executions through supporting charts and detail tables

Access to the dashboard is controlled by the Observability Access permission.

User and Configuration Guide Reference:

• Transaction Monitoring – Observability Dashboard

• Expiry notifications: the Whitelist button now shows a health indicator for entries pending approval, expiring within 7 days, or expired. Only visible to users with the approve permission.
• Active whitelist chip on alerts: a Whitelisted N chip appears next to the main entity name in an alert when N active whitelists exist, with a hover popover and quick access to the drawer.
• Whitelist Source: each entry now records whether it was created manually or from an alert (with a link to the originating Alert ID).
• Status summary header: the Whitelist drawer now shows a count per status at the top; clicking a status filters the list.
• Expired request handling: requests that pass their expiry date without being actioned are marked Expired with a banner; Approve/Reject buttons are removed.
• Wildcard display: wildcard entries now show All rules or All counterparties with a globe icon instead of All.
• Request Notes character counter: the Notes field now displays a live count against the 500-character limit.

User Guide Reference: Transaction Monitoring -> Entity Whitelisting

A new collapsible Alert Assessment Activity panel is available on the My Alerts dashboard, showing the 10 most recently assessed alerts by default. Select View More to expand to 20. Hover over an alert to see a quick popover, or open it directly in the right-hand drawer. The panel is collapsed by default and will collapse automatically when the drawer is opened.

Configurable entity data​

A new Right Hand Drawer Display dropdown is available in the Entity Profile Configuration area, allowing configurators to select which requirement category is shown in the entity panel on the Alert Details page. The panel title updates to reflect the selected category name. If no category is selected, existing behaviour is preserved.

Financial Crime Risk (FCR) tab​

The FCR tab is now available in the entity right-hand drawer on the Alert Details page, consistent with the entity profile page. Visibility follows existing FCR permissions.

Live Search Across Dashboards and Grids​

Search inputs now update results automatically as you type so there is no need to press Enter or click search.

User Guide Reference: Transaction Monitoring -> Transaction Monitoring Investigations

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

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

These updates reduce duplicative reference-list maintenance, improve change management across rules, and keep rule behaviour transparent when the underlying data evolves.

User Guide Reference: TM User Guide > Rules Manager

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.

Key Capabilities​

• Trigger export generation for a specific date via:

  POST /api/v1/data-export/trigger
  → Returns a trigger_id

• Retrieve the export report via:

  GET /api/v1/data-export/{trigger_id}
  → Available once processing is complete

• Poll the retrieval endpoint using the trigger_id to check readiness

• Download the exported file via a time-limited URL
  → Valid for 15 minutes from issuance

• Access export data and associated metadata for up to 30 days (tenant-configurable), aligned with Observability API retention policies

Report Contents​

The export includes:

• Transaction modification IDs only for the requested date

The export does not include:

• Full transaction payloads
• Alert data
• Alert-to-transaction relationships
• Rule execution details

Prerequisites​

• Export files must be downloaded within the 15-minute URL validity window
• If the URL expires, a new retrieval request is required to obtain a fresh download link

Recommended Practice: Periodic Download & Archival​

To maintain long-term transaction reconciliation records for compliance, audit, and operational workflows, we recommend establishing a regular download schedule—for example, weekly—and archiving reports to your own systems. Once downloaded, you own the data and can retain it as long as your requirements dictate, independent of the Observability API data retention policies.

Docs​

• API Documentation
• API Changelog

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

These updates provide better transparency, improved performance control, and a more accurate representation of rule behaviour during backtesting.

User Guide Reference: TM User Guide > Rules Manager

• 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.

User Guide Reference: Alerts Integrated Workflow

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.

User Guide Reference: Alerts Integrated Workflow -> Entity Whitelisting

User Guide Reference: Fenergo Transaction Monitoring ->Behavioural Risk

Key benefits:

• Real-time visibility: Poll execution progress at any point during a run, with completion percentage and per-rule status breakdown.
• Alert aggregation: See total and deduplicated alert counts across the entire execution and per rule — available as soon as data is indexed.
• Timing metrics: Track how long an execution took via first event, last event, and total duration in seconds.
• Clear status semantics: Execution states are unambiguous — terminal states (succeeded, failed, partially_failed) indicate a completed run; non-terminal states (requested, in_progress, in_progress_with_failures) indicate a run still in flight.

API Reference: Rule Execution Status Endpoint

Key benefits:

• Operational transparency: See exactly which rules are scheduled to run on any given date, so you know what to expect and when.
• Schedule verification: Confirm a rule's next execution times immediately after making configuration changes.
• Simple query interface: Query by date or by rule ID — no technical setup required.

API Reference: Rule Schedule Endpoint

Key benefits:

• Fast remediation: Re-run impacted rules for a historical date after fixing data/config issues.
• Operational agility: Perform targeted reprocessing without full pipeline replays.
• Controlled and safe: Built-in guardrails ensure reruns remain predictable and compliant.

API Reference: Rules Rerun API

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

User Guide Reference: Alerts Integrated Workflow

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.

User Guide Reference: Alerts Integrated Workflow -> Manual Alerts

• 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

User Guide Reference: Fenergo Transaction Monitoring -> Behavioural Risk

User Guide Reference: Fenergo Transaction Monitoring ->Behavioural Risk

{ 
  ...
  "receiver": {
    "by_external_id": "B7FA3237-72F6-49B3-9BA9-D35AC74F54EC",
    "external_entity_type": "business",
    "business": {
      ...
      "external_id": "3CB6FBC9-7106-42C2-988B-C6F363E58381",
      ...
    }
  },
  ...
}

In such cases the API will respond with:

"Only provide an entity by_external_id value or an embedded entity external_id value, not both."

Please only specify the entity via the by_external_id, e.g.:

{
  ...
  "receiver": {
    "by_external_id": "B7FA3237-72F6-49B3-9BA9-D35AC74F54EC"
  },
  ...
}

Or via the embedded entity object, e.g.:

{
  ...
  "receiver": {
    "external_entity_type": "business",
    "business": {
      ...
      "external_id": "3CB6FBC9-7106-42C2-988B-C6F363E58381",
      ...
    }
  },
  ...
}

As part of this optimisation, ANY-true groups will only exit the rule execution when all referenced parameters in the conditions have null values or if they all result in a 'not present' result , while ALL-true exits execution when any referenced field is null or results in a not-present result .

Fields that are present but do not meet the specified condition are evaluated normally and impact only the condition outcome, not rule execution flow.

For example :

ANY-true: (field x == a; field y == b) -> exit if x is None AND y is None ALL-true: (field x == a; field y == b) -> exit if x is None OR y is None

User Guide Reference: TM User Guide > Rules Manager

User Guide Reference: Alerts Integrated Workflow ->Alert Scoring

• Ensuring All Alerts, My Alerts, Grouped Alerts and Alerts with this transaction grids are aligned and contain the relevant dataset including Alert Score and Stage
• Ensuring each alert grid has the full set of available action, per row and in bulk
• Aligning sorting and filtering on each grid, default sorting by date
• Introducing saved filters
• Extend default view to 20 rows with option to extend to 50
• Include closed alerts on dashboard
• Improve bulk select usability

Transaction Grids Realignment of tramsaction grids:

• Ensuring transaction grids are aligned and uniform
• Add external id
• Add sorting and filtering, default sorting by date

Other CX Enhancements

• Add Alert Outcome chip to confirmation modal and completed alert
• Add sticky tabs to Alert dashbaord

User Guide Reference: Alerts Integrated Workflow

Alert groups can be created from the All Alerts/My Alerts dashboard and viewed on the new Groups tab.

Bulk Assignment​

Alerts can be assigned in bulk.

Bulk Assessment​

Alerts which are assigned to a user can be assessed in bulk.

Entity Access layers for Alerts​

Alerts access is controlled based on entities access layers.

Key benefits:

• Targeted daily runs: Execute a specific subset of rules by providing rule_ids, or run all live rules scheduled for a date.
• On-demand execution: Trigger rule execution for any past date without waiting for scheduled runs.
• Transparent outcomes: The response clearly separates accepted and rejected rules, with per-rule rejection reasons for easy diagnosis.
• Safe reprocessing: Use the force flag to rerun a rule that has already executed for a given date, with full control over which rules are reprocessed.

API Reference: Rule Execution API

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.

Some key aspects of the Fenergo Transaction Monitoring Observability API v1.0.0:

• Traceability of Modification Ingestion: Track the status of ingested transactions within the transaction monitoring pipeline.
• Auditability: Designed to support compliance and operational audit requirements by exposing traceable rule execution paths.
• Flexible request types: Pass Request to the API to get ingestion status by date(s), by specific modification ID or retrieve only failed modifications per date.
• Transactions can be queried for up to 30 days in the past.
• API Reference: TM observability

User Guide Reference: TM User Guide > Rules Manager

User Guide Reference: TM User Guide > Rules Manager

User Guide Reference: TM User Guide > Rules Manager

User Guide Reference: TM User Guide >This update needs to be performed by technical consultants in the backend.