...
A rule processor configuration document typically contains the following information:
Rule configuration metadata
...
...
{
"id": "003@1.0.0",
"cfg": "1.0.0",
"desc": "Account dormancy - creditor"
}A config object, that
may contain
...
| Code Block |
|---|
"config": {
"parameters": {
"maxQueryRange": 86400000,
"tolerance": 0.1
}
} |
...
a number of parameters
may contain a number of exit conditions
...
| Code Block |
|---|
"config": {
"exitConditions": [
{
"subRuleRef": ".x00",
"outcome": false,
"reason": "Incoming transaction is unsuccessful"
},
{
"subRuleRef": ".x01",
"outcome": false,
"reason": "Insufficient transaction history"
}
]
} |
The config object will also contains either result bands, for example:
| Code Block |
|---|
"config": {
"bands": [
{
"subRuleRef": ".01",
"lowerLimit": 0,
"upperLimit": 18,
"outcome": true,
"reason": "The debtor is younger than 18 years old"
},
{
"subRuleRef": ".02",
"lowerLimit": 18,
"upperLimit": 30,
"outcome": true,
"reason": "The debtor is 18 years or older and younger than 55 years of age"
},
{
"subRuleRef": ".04",
"lowerLimit": 50,
"outcome": true,
"reason": "The debtor is 55 years or older"
}
]
} |
or alternatively result cases, for example:
...
will contains either result bands
or alternatively will contain result cases
Rule configuration metadata
The rule configuration “header” contains metadata that describes the rule. The metadata includes the following attributes:
ididentifies the specific processor and version related to the configurationcfgis the unique version of the configuration. Multiple different versions of a config can co-exist simultaneously in the platform.descoffers a readable description of the rule
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 configuration object - parameters
A rule processor’s parameters are used to define how a rule processor will operate to evaluate the incoming message. The requirement for the parameters are coded into the rule processor and must be provided in the configuration for the rule processor to deliver a successful outcome. If any of the required parameters are missing, the rule processor will still deliver a result, but it will be a default error outcome. Parameters are given descriptive names to assist the operator in specifying them correctly. Parameters often differ from one rule to the next, but typically define thresholds and time-frames for the historical queries that are executed inside a rule processor. Some notable examples:
Parameter | Description |
|---|---|
| The time-frame that defines the intervals into which a histogram is partitioned. Some rules perform a statistical analysis of behaviour over time and partitions the historical data into a histogram. This parameter defines, in milliseconds, the time-frame of each interval. |
| The maximum number of records to return in the query. This parameter limits the number of results that can be returned from the database. |
| A time (in milliseconds) that limits the maximum extent of a historical query. A query with a value of 86400000 would only look up messages received within the last 24 hours. |
| The least number of transactions required for the rule processor to produce a result. Some statistical algorithms required at least a certain number of data-points to be able to render a useful result. If the minimum number of transactions cannot be retrieved, the rule processor will raised a non-deterministic exit condition. |
| A margin of error for an evaluation against a threshold. With a tolerance of 0 (zero) the match against a target value would have to be exact, but with a tolerance value of 0.1, the match could be in a range either 10% below or above the threshold value. |
Example:
| Code Block |
|---|
"config": {
"parameters": {
"maxQueryRange": 86400000,
"commission": 0.1,
"tolerance": 0.1
}, |
If a rule processor does not use any parameters, the parameters object may either be empty (parameters{}) or omitted entirely.
The configuration object - exit conditions
3. Version Management
3.1. Introduction and Basics
...
The active network map ultimately defines the scope of a particular evaluation, right down to the specific processors and their versions that are going to be used, as well as the specific version of the processor configuration required. If any of the components in a network map changes, a new network map must be deployed and activated to replace the previous iteration of the network map.
...
References
...
In its current configuration, the platform only evaluates the pacs.002 as the trigger payload for the rule processors and typologies have only been defined with the final status of a payment transaction in mind.
The typology processor is not currently configured to interdict the transaction when the threshold is breached; only investigations are commissioned once the evaluation of all the typologies are complete.
https://frmscoe.atlassian.net/wiki/spaces/FRMS/pages/76906497/Configuration+management#References%3A
An explicit version reference has been planned for development to make it easier for an operator to link an evaluation result to the specific originating network map.