Skip to main content

Behavioural Risk

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.

Specifying entity IDs in trxs sent to the single transaction ingestion API

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",
      ...
    }
  },
  ...
}

Optimise rule execution logic inside ANY TRUE condition groups

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

Grid Alignment

Alert Grids Realignment of alert grids:

  • 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

TM Rule Execution

The TM Rule Execution API lets you trigger the execution of scheduled rules for a specific date — supporting both standard scheduled runs and targeted reruns after data or configuration corrections.