...

• Typology configuration metadata

• A rules object, that specifies the weighting for each rule result by sub-rule reference

• An expression object, that defines the formula for calculating the typology score out of the rule result weightings

• A workflow object, that contains the alert and interdiction thresholds against which the typology score will be measured

...

The combination of the id and cfg strings forms a unique identifier for every rule configuration and is sometimes compiled into a database key, though this is not essential: the database enforces the uniqueness of any configuration to make sure that a specific version of a configuration can never be over-written.

The Rules object

The rules object is an array that contains an element for every possible outcome for each of the rule results that can be received from the rule processors in scope for the typology.

...

All the possible outcomes from the rule processors are encapsulated in each rule’s configuration, with the exception of the .err outcome that is not listed in the rule configuration for reasons mentioned above. When composing the typology configuration, the user must remember to include the .err outcome, but the rest of the rule results (exit conditions and banded/cased results) can be directly reconciled with the elements in the rules object.

Each rule result element in the rules array contains the same attributes:

The expression object

The expression object in the typology processor defines the formula that is used to calculate the typology score. The expression is able to accommodate any formula composed out of a combination of multiplication (*), division (/), addition (+) and subtraction (-) operations.

In its most basic implementation, the expression is merely a sum of all the weighted rule results. This also means that every deterministic rule listed in the rules array object in the typology configuration must be represented in the expression as a term, otherwise the rule weighting will not be taken into account during the score calculation.

The expression object contains the operators and terms that make up the typology scoring formula. Operators and their associated terms are defined as a series of nested objects in the JSON structure. For example, if wanted to add two terms, a and b, I would start the expression with the operator and then nest the terms beneath it, as follows:

a + b

"expression": {
  "operator": "+",
  "terms": ["a", "b"]
}

In the platform the terms a and b would be represented by their unique id and cfg combination:

{
  "id": "001@1.0.0",
  "cfg": "1.0.0"
}

We don’t have to also supply a specific sub-rule reference: each rule processor only submits one of its possible rule results at a time.

If, for example, we wanted to apply an additional multiplier to the formula (e.g. (a + b) * c, the resulting expression would be structured as follows:

"expression": {
  "operator": "*",
  "terms": ["c",
    "operator":"+",
    "terms": ["a", "b"]
  ]
}

By example, a complete expression for a typology that relies on 4 rule results and calculates the typology score as a sum of the rule result weightings would be composed as follows:

"expression": {
  "operator": "+",
  "terms": [
    {
      "id": "001@1.0.0",
      "cfg": "1.0.0"
    },
    {
      "id": "002@1.0.0",
      "cfg": "1.0.0"
    },
    {
      "id": "003@1.0.0",
      "cfg": "1.0.0"
    },
    {
      "id": "004@1.0.0",
      "cfg": "1.0.0"
    },    
  ]
}

Mathematically, this expression would translate to:

...

or simply:

typology score = rule 001 weighting + rule 002 weighting + rule 003 weighting + rule 004 weighting

The workflow object

The workflow object determines the thresholds according to which the typology processor will decide if an action is necessary in response to the typology score. A typology can be configured with two separate thresholds:

alert: this threshold will only alert an investigator if the threshold was breached, but will not force the typology processor to take any other direct action

interdiction: if breached, this threshold will force the typology processor to issue a message to the client platform to block the transaction. This action will also force an alert to an investigator at the end of the evaluation process.

3. Version Management

3.1. Introduction and Basics

...