...
2.1. Rule Processor Configuration
...
Introduction
A rule processor is a custom-built module that evaluates an incoming message according to its code. When a new rule processor is developed, the rule designer will specify both the input parameters for the rule, as well as the output results. Changes to these attributes can alter a rule processor’s behavior and it is expected that these attributes are hosted in the rule configuration so that the rule processor behavior can be altered by updating the configuration instead of changing the rule processor code.
...
Term | Milliseconds |
|---|---|
second | 1,000 |
minute | 60,000 |
hour | 3,600,000 |
day | 86,400,000 |
week | 604,800,000 |
month (30.44 days) | 2,629,743,000 |
year (365.24 days) | 31,556,926,000 |
Rule results - cased results
In contrast to the partitioning of a result range as in banded results, cased results are a collection of discrete and explicit outcomes for a rule processor out of which the rule processor will determine the specific result applicable to the evaluation it performed.
Case results do not have upper or lower limits to define a range of values within which a rule result is placed. Instead every case result is simply evaluated with an = operator. The rule result is either that specific case value, or a different one.
It is extremely important that every case-based rule configuration contains a catch-all “else” outcome that defines an outcome for the rule processor if none of the listed case results can be matched. By convention, this “else” outcome is attached to the .00 sub-rule reference outcome and rule developers and configurers should reserve this sub-rule reference exclusively for this purpose.
Beyond the default “else” outcome, the cased rule processor configuration can contain any number of results.
The rule result cases are specified in the config object in the rule configuration as an array of elements under a cases object:
| Code Block |
|---|
"config": {
"cases": [
{
"subRuleRef": ".00",
"outcome": false,
"reason": "Value found is non-deterministic"
},
{
"value": "P2B",
"subRuleRef": ".01",
"outcome": true,
"reason": "The transaction is a merchant payment"
},
{
"value": "P2P",
"subRuleRef": ".02",
"outcome": true,
"reason": "The transaction is a peer-to-peer transfer"
}
]
} |
Each rule result case contains the same information:
Attribute | Description |
|---|---|
| This attribute defines the specific value that will be matched in the rule processor ( Every case contains a value, with the exception of the default “else” case. Values can be either strings, encapsulated in quotes, or numbers, without quotes. |
| Every rule processor is capable of reporting a number of different outcomes, but only a single outcome from the complete set is ultimately delivered to the typology processor. Each outcome is defined by a unique sub-rule reference identifier to differentiate the delivered outcome from the others and also to allow the typology processor to apply a unique weighting to that specific outcome. We have elected to assign a numeric sequence to the sub-rule references for result bands, prefaced with a dot (“.”) separator, but this format is not mandatory for the sub-rule reference string. Any descriptive and unique string would be an acceptable sub-rule reference. By convention, the default “else” outcome has a sub-rule reference of |
| The configuration file defines whether the result delivered by the rule processor is flagged as either |
| The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. |
2.2. Typology Configuration
Introduction
The typology processor collects rule results and compiles the rule results into a variety of fraud and money laundering scenarios, called typologies. Unlike rule processors that have specific and unique functions guided by their individual configurations, the typology processor is a centralized processor that arranges rules into scenarios based on multiple typology configurations. Effectively, a typology is described solely by its configuration and does not otherwise exist as a physical processor. When the typology processor receives a rule result, it determines which typologies rely on the result and the various typology configurations are used to formulate the individual scenarios.
A typology configuration contains three major elements. It defines the weighting with which rule results contribute to the typology score, the formula used to compose all of the weighted rule results into the typology score and then the thresholds against which the typology score will be measured to determine if any action needs to be taken based on the score.
3. Version Management
3.1. Introduction and Basics
...