TM Rule Schedule API v1.0.0
The TM Rule Schedule API gives you visibility into your rules' execution schedule — useful for understanding upcoming rule runs and verifying schedule changes after configuration updates.
The TM Rule Schedule API 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.
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:
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:
The Behavioural Risk Feature is a capability that identifies changes in an entity's actual transactional behaviour compared to their declared Expected Activity. When material deviations are detected, the system re-evaluates risk and can automatically trigger a journey if a higher risk threshold is reached. The feature operates as a nightly automated process, comparing expected activity held on the verified entity profile against actual transactional data observed over a 12-month period.
Going forward, the single transaction ingestion API will no longer accept transactions that include both the entity's by_external_id and the embedded entity's external_id. For example, the following construction is no longer allowed:
{
...
"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",
...
}
},
...
}
An optimisation has been implemented to ensure more robust and predictable rule execution when using the ANY-true and ALL-true operators.
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
Alert Grids Realignment of alert grids:
Transaction Grids Realignment of tramsaction grids:
Other CX Enhancements