Alerts Integrated Workflow - new alerts workflow using Fenergo Alert Object, new Alerts Dashbaord with associated alerts permissions set. Configurable Alert journey. Transaction and alerts view from Entity Profile.

Placed restrictions on ID integer fields to only accept 32-bit integer values

The new set of API's provide observability capabilities, allowing users to track the progress and outcomes of data loads and validations more effectively. This eliminates the need for extensive technical intervention, streamlining the monitoring process and improving overall system transparency.

Calculations can now be grouped with entity data rules in the past transaction section. This enhancement supports definition of multiple aggregate/calculation groups, each with its own Entity data rule relationship, and conditional logic (Any True / All True) can be applied at the parent level for enhanced detection capabilities.

A new option where users can select when a lookback query can start from. The options are 'immediately prior to the rule execution time' or 'a specific number of days in the past'. this allows the user to exclude a certain time period or to avoid overlapping time periods, when comparing two aggregates. This enhancement allows for more flexibility in AML rule building by supporting selection of specific starting points when building a lookback query

For tenants that use the integrated CLM and TM solution, a new category of parameters is now available in the Rule Manager UI, enabling users to build rules that can reference KYC attributes of an entity. Before using KYC attributes in the Rule Manager, the required KYC attribute checks must be pre-created and approved in the 'Entity Data Rules' module. This enhancement allows for more comprehensive AML rule building by combining KYC information from an entity profile with transaction conditions.

A new field, 'query limit' has been introduced in the tenant configuration file to control the query limit for live Elastic search queries during rule execution. This field determines how far back in time a rule can search. The default limit is set to 30 days, but it can now be increased to a maximum of 1 year (365 days). However, this extended limit (beyond 30 days) should only be applied to tenants where we have a contractual agreement to process a low volume of transaction data. A low-volume tenant typically processes around 2,000 transactions per day, or around 60,000 transactions over a 90-day period. This configuration allows users to input a query period in the rule manager that exceeds the previous 30-day limit, based on the value set in the system settings. .

First iteration of Entity data rules which can be integrated with python rules. Entity Data, Product data and Related Party data can be evaluated.

General Aggregate Comparisons​

Compare Aggregates Across Different Periods

• You can now compare one aggregate from one period against another aggregate from a different period, both within the maximum supported period of up to 30 days. This allows to detect unusual patterns over short-term periods.

Compare Aggregates Against Custom Values

• Continue to build rules by comparing an aggregate from one period (up to 30 days) against a custom value, maintaining the straightforward rule-building process you are familiar with in version 1.0

Real-Time Transaction Comparisons​

Compare Aggregates Against Latest Transaction Values

• Introduce real-time monitoring by comparing an aggregate from one period against a value from the most recent transaction, enabling prompt detection.

Custom Aggregates and Arithmetic Expressions​

Create and Combine Custom Aggregates

• Gain more control by creating your own aggregates and combining them using simple arithmetic expressions.

For example, you can now express rules like Variable A / Variable B > Variable C, allowing for more nuanced rules.