7) Abstraction for Fraud Prevention using Account Financial Transactions.

This Blog entry is from the Getting Started in Jube section in Learn Jube.

The In Model Abstraction Rules page is where rules are created for the aggregation of data available in the Cache. The Abstractions Rules functionality is one of the most intrinsic processes in the Entity Model processing being responsible for the creations of aggregate statistics based on the content of the cache of data retained for that model. The abstraction rules are grouped together by their search keys.

A search key is a value that will be used as a predicate in retrieval of data for the subsequent execution of Abstraction rules that use that search key. For example, if a transaction is being processed through a model, if an account identifier is configured to be a search key, a selection of all records in the model cache will be returned where that account identifier matches (put simply it will return all transactions for that customer account). Search keys are defined in the Request XPath definition and there can be many search keys - thus cache database queries - per transaction being executed through the model. The process is different when a Search Key is defined to be retrieved from a cache, as these values are pre-calculated by the Search Key Cache thread, documented extensively in its own right.

Firstly, Search Keys need to be set up, in this example IP, by revisiting the Request XPath page via Entity Models >>> References >>> Request XPath:


Expand on the mode tree on the left hand side to expose all Request XPath for this model, then click on IP:


For the Request XPath, click the checkbox titled Search Key:


With Search Key having been checked, click on the Update button towards the base of the page:


With a search key now being available, navigate through the menu as Entity Models >>> Abstraction and Fitting >>> In Model Abstraction. The page is presented as a tree objects for the purposes of administering a model child objects:


Click on the model towards the left hand side to add an Abstraction Rule:


The Page exists to create Abstraction Rules which are code fragments will will be compiled into the Jube Engine. Abstraction Rules accept data and TTL Counter objects and tests the code fragment for equality, returning a boolean flag to that effect. The Rule and Code Constructor Comprises the following:




The fields created in the Request XPath page and Inline Scripts (if allocated).

TTL Counters

The TLL Counter and their current incremented values.

The page accepts the following parameters in the construction of Abstraction Rules:



This Example


The scope whether the rule is to be executed on a list of records having been returned from the Cache or only upon the transaction currently being processed through the model. None would imply that the scope of the Abstraction Rule is only the current transaction being processed and if it matches, then a 1 will be returned, otherwise zero (keeping in mind that Neural Networks will seek to weight it, hence the numeric values). If Entity Search would imply that a retrieval from the Mongo Datbase need be taken place and the Abstraction Rule is going to be tested against each transaction returned.

Entity Search

Search Key

The Search Key is the basis for several data retrievals to be made of the Mongo Database. For example, if a Search Key is specified to be an IP, then it would imply that a select is going to be made of the Mongo Database for all transaction matching on the IP of the current transaction thereafter applying the Abstraction Rule on each of the records to test for a match.


Search Interval

The Search Interval is the time threshold reaching back from the Reference Date for the transaction being processed whereby only transactions exceeding this threshold are eligible for matching. For example, if a Search Interval is configured for 1 Day (taking the Search Interval and Search Value together) then this would imply that only records greater than the Reference Date minus One Day is eligible. It is worthy of note that the Search Interval and Search Value are not used in the recall from the Mongo Database, that will still return everything matching on the key up to the fetch limit specified in the model definition. The Search Interval is taken together with the Search Value.


Search Value

As Search Interval, with the Search value being comprising the length of time to reach back from the Reference Date.


Offset Type

All data matching on a search key is retrieved from the cache. The Offset type helps to select data from a subset of these records. This can be helpful if analysis need be done only on the last x records, for example. In most cases it will be set to none.


Offset Interval

The number of intervals to be offset by, for example the last x number of records returned from the cache.


Function Type

The process of aggregating the matches is different from the process of testing and matching the Abstraction Rules itself. The process of aggregation takes place after all matching has take place and the transaction matches for the rule have been set aside. The Function Type is the aggregation type to take place and is extensively documented in the Abstraction Function Definitions of this document. For example, if a Sum function is specified, then the function will look to count up records using the Function Key field (e.g. Transaction Amount).


Function Key

The Function Key is available only on certain Function Types and represents the fields inside the transaction that are to be used for aggregation. For example, if the Sum Function Type is specified and the Function Key is specified as the Transaction Amount, the aggregation will seek to create a Sum for all of the Transaction Amounts. In the case of a Count, no Function Key would be available, as the Function Type would seek to count up the matches only.


Complete the page with the parameters as prescribed above, setting a rule to match on everything:


Click the Add button to create a version of this Abstraction Rule:


Allow the platform a couple of moments to syncronise then post an Account Financial Transaction:


It can be seen that the sum of all events in the last day has been aggregated, and this will increase on each event. This value is available for subsequent rules.