...
Configuration documents are essentially files that contain a processor-specific configuration object in JSON format. The recommended way to upload the configuration file to the appropriate configuration database and collection is via Arango DB’s HTTP API that is deployed as standard during platform deployment.
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.
A rule processor configuration document typically contains the following information:
Rule configuration metadata
A config object, that
may contain a number of parameters
may contain a number of exit conditions
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
...
evaluationIntervalTime
...
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.
...
maxQueryLimit
...
The maximum number of records to return in the query. This parameter limits the number of results that can be returned from the database.
...
maxQueryRange
...
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.
...
minimumNumberOfTransactions
...
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.
...
tolerance
...
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
A rule processor’s exit conditions ensure that a rule processor is always able to produce a result, even if the rule processor is unable to reach a definitive, deterministic outcome. Exit conditions account for non-deterministic exceptions in the rule processor’s behavior. The exit conditions are coded into the rule processor and each exit condition The platform processes configurations in a specific order to evaluate an incoming transaction. Starting with the Channel Router & Setup Processor (CRSP) that interprets the network map for routing, then following with the rule processors that interpret their individual rule configurations to determine how to evaluate the transaction, and then concluding with the typology processor that uses a variety of typology configurations to summarize rule results into scenarios.
...
The development cycle for the platform processors and their associated configurations follow a slightly different flow. The development and configuration process follows somewhat loosely cascading dependencies amongst the configuration documents: typologies rely on rules, and the network map that defines routing relies on typology-and-rule structures.
Typically, a rule processor is developed first to implement a new rule to evaluate an incoming transaction. The rule processor will already need a configuration for testing purposes during the development, but this may not be the final configuration with the default processor calibration. Regardless, the rule processor may be deployed simultaneously with an initial configuration, or the processor and its configuration may be deployed independently.
Rule results roll up into typologies through a typology configuration. One would typically only start composing a typology once the target rules have been developed and deployed, though sometimes rules may be added to, or removed from a typology, and through that its configuration. Without a view of the target rules and their configurations, blindly composing a typology would be very difficult, so this step usually follows the completion of the rules.
Finally, the typologies and rules are bound together into the network map and attached to the specific transaction type for which the rules and typologies are intended. The network map defines the rules that should receive the transaction for evaluation, and also the routing to the typologies composed out of the rules.
...
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.
A rule processor configuration document typically contains the following information:
Rule configuration metadata
A config object, that
may contain a number of parameters
may contain a number of exit conditions
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 rule processor and version related to the configurationcfgis the unique version of the rule configuration. Multiple different versions of a rule configuration can co-exist simultaneously in the platformdescoffers 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 exit conditions required parameters are missing, the rule processor will still deliver a result, but it will be a default error outcome complaining about the missing exit condition related to the specific exit condition code.
By convention, exit condition codes are prefaced with an 'x' to differentiate them from regular rule results that have no prefix.
From a configuration perspective, the only real purpose for including the exit conditions in the configuration file is to accommodate implementation-specific and user-defined descriptions for the exit conditions, and, in a future release, accommodate multi-language support.
A rule processor may use zero or many different exit conditions. Exit conditions are arranged in an array object inside the configuration object. The exit conditions array object may be an empty placeholder if no exit conditions are defined, or omitted altogether.
Exit conditions cover a number of different exception conditions for rule processors. In principle, each distinct exit condition code relates to a specific type or class of exit condition and this principle has been generally applied to all rule processors that share common exit conditions as follows:
...
Code
...
Description
...
Example(s)
...
.x00
...
This condition applies to rule processors that rely on the current transaction being successful in order for the rule to produce a meaningful result. Unsuccessful transactions are often not processed to spare system resources or because the unsuccessful transaction means that the rule processor is unable to function as designed.
...
Unsuccessful transaction
...
.x01
...
For certain rules, a specific minimum number of historical transactions are required for the rule processor to produce an effective result. This exit condition will be reported if the minimum number of historical records cannot be retrieved in the rule processor.
...
Insufficient transaction history
At least 50 historical transactions are required
...
.x02
...
Currently unused.
...
.x03
...
The statistical analyses employed in some rule processors evaluate trends in behavior over a number of transactions over a period of time. While the trend itself can be categorized and reported by the regular rule results, some results are not part of an automatable scaled result. This exception provides an outcome when the historical period does not show a clear trend, but the most recent period shows an upturn.
...
No variance in transaction history and the volume of recent incoming transactions shows an increase
...
.x04
...
Similar to .x03, but this exception provides an outcome when the historical period does not show a clear trend, but the most recent period shows an downturn.
...
No variance in transaction history and the volume of recent incoming transactions is less than or equal to the historical average
Example:
| Code Block |
|---|
"config": {
"exitConditions": [
{
"subRuleRef": ".x00",
"outcome": false,
"reason": "Unsuccessful transaction"
},
{
"subRuleRef": ".x01",
"outcome": false,
"reason": "Insufficient transaction history"
}
] |
Each exit condition contains the same attributes:
...
Attribute
...
Description
...
subRuleRef
...
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.
By convention, the exit condition sub-rule references are prefaced with an 'x'.
...
outcome
...
The configuration file defines whether the result delivered by the rule processor is flagged as either true or false. The flag is somewhat arbitrary, but by convention we choose to assign a true flag to deterministic results that will have a weighting impact on the typology score and we assign a false flag to non-deterministic results that will not have a weighting impact on the typology score.
Exit conditions are usually non-deterministic.
...
reason9
...
The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result.
| Info |
|---|
The |
The configuration object - rule results
While the parameters and exit conditions may be optional for a specific rule processor, the core function and output of a rule processor is contained in the results object. Rule processors offer two different kinds of rule results:
Banded results, where the result from the rule processor is categorized into one out of a number of discrete bands that partition a contiguous range of possible results.
...
Cased results, where the result from the rule processor is an explicit value from a list of discrete and explicit values.
...
The rule processor’s core purpose is to produce a definitive deterministic result based on its programmed behavioral analysis of historical data. The rule configuration defines the bands or values for which rule results can be provided.
...
It is extremely important that the configuration of a rule processor does not leave any gaps in the results, whether banded or cased. Every possible outcome of a rule result must be accounted for, otherwise the rule processor may deliver a result that the typology processor cannot interpret. In the event that a rule processor result misses the configured results, the rule processor will issue an error (.err) result with a reason description of Value provided undefined, so cannot determine rule outcome.
Rule results - banded results
Banded results are partitions in a contiguous range of results, effectively from -∞ to +∞. When a target value is evaluated against a result band the lower limit of a band is always evaluated with the >= operator and the upper limit is always evaluated with the < operator. This way, we can configure the upper limit of one band and the lower limit of the next band with the exact same value to make sure there is no overlap between bands and also no gap.
...
Where a lower limit is not provided, the rule processor will assume the intended target lower limit is -∞.
Where an upper limit is not provided, the rule processor will assume the intended target upper limit is +∞.
A rule processor with a banded results configuration can have an unlimited number of specified bands.
The rule result bands are specified in the config object in the rule configuration as an array of elements under a bands object:
| Code Block |
|---|
"config": {
"bands": [
{
"subRuleRef": ".01",
"upperLimit": 86400000,
"outcome": true,
"reason": "Account is less than 1 day old"
},
{
"subRuleRef": ".02",
"lowerLimit": 86400000,
"upperLimit": 2592000000,
"outcome": true,
"reason": "Account is between 1 and 30 days old"
},
{
"subRuleRef": ".03",
"lowerLimit": 2592000000,
"outcome": true,
"reason": "Account is more than 30 days old"
}
]
} |
Each rule result band contains the same information:
...
Attribute
...
Description
...
subRuleRef
...
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.
...
lowerLimit
...
This attribute defines the lower limit of the band range and is evaluated inclusively (>=).
Where a lower limit is not provided, the rule processor will assume the intended target lower limit is -∞. Unless the very first result band in a configuration has a clear and unambiguous lower limit, it is often omitted.
...
upperLimit
...
This attribute defines the upper limit of the band range and is evaluated exclusively (<).
Where an upper limit is not provided, the rule processor will assume the intended target upper limit is +∞. Unless the very last result band in a configuration has a clear and unambiguous upper limit, it is often omitted.
...
outcome
...
The configuration file defines whether the result delivered by the rule processor is flagged as either true or false. The flag is somewhat arbitrary, but by convention we choose to assign a true flag to deterministic results that will have a weighting impact on the typology score and we assign a false flag to non-deterministic results that will not have a weighting impact on the typology score.
...
reason9
...
The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result.
One of the most frequent limit values in use in the platform is based on time-frames. In the platform, all time-frames and associated limits are represented in milliseconds. The following table reflects the conventional milliseconds for different time terms in our configurations:
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
...
value
...
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.
...
subRuleRef
...
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 .00.
...
outcome
...
The configuration file defines whether the result delivered by the rule processor is flagged as either true or false. The flag is somewhat arbitrary, but by convention we choose to assign a true flag to deterministic results that will have a weighting impact on the typology score and we assign a false flag to non-deterministic results that will not have a weighting impact on the typology score.
...
reason9
...
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 processor configuration document typically contains the following information:
...
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
...
. 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
A rule processor’s exit conditions ensure that a rule processor is always able to produce a result, even if the rule processor is unable to reach a definitive, deterministic outcome. Exit conditions account for non-deterministic exceptions in the rule processor’s behavior. The exit conditions are coded into the rule processor and each exit condition must be provided in the configuration for the rule processor to deliver a successful outcome. If any of the exit conditions are missing, the rule processor will still deliver a result, but it will be error outcome complaining about the missing exit condition related to the specific exit condition code.
By convention, exit condition codes are prefaced with an 'x' to differentiate them from regular rule results that have no prefix.
From a configuration perspective, the only real purpose for including the exit conditions in the configuration file is to accommodate implementation-specific and user-defined descriptions for the exit conditions, and, in a future release, accommodate multi-language support.
A rule processor may use zero or many different exit conditions. Exit conditions are arranged in an array object inside the configuration object. The exit conditions array object may be an empty placeholder if no exit conditions are defined, or omitted altogether.
Exit conditions cover a number of different exception conditions for rule processors. In principle, each distinct exit condition code relates to a specific type or class of exit condition and this principle has been generally applied to all rule processors that share common exit conditions as follows:
Code | Description | Example(s) |
|---|---|---|
| This condition applies to rule processors that rely on the current transaction being successful in order for the rule to produce a meaningful result. Unsuccessful transactions are often not processed to spare system resources or because the unsuccessful transaction means that the rule processor is unable to function as designed. |
|
| For certain rules, a specific minimum number of historical transactions are required for the rule processor to produce an effective result. This exit condition will be reported if the minimum number of historical records cannot be retrieved in the rule processor. |
|
| Currently unused. | |
| The statistical analyses employed in some rule processors evaluate trends in behavior over a number of transactions over a period of time. While the trend itself can be categorized and reported by the regular rule results, some results are not part of an automatable scaled result. This exception provides an outcome when the historical period does not show a clear trend, but the most recent period shows an upturn. |
|
| Similar to |
|
Example:
| Code Block |
|---|
"config": {
"exitConditions": [
{
"subRuleRef": ".x00",
"outcome": false,
"reason": "Unsuccessful transaction"
},
{
"subRuleRef": ".x01",
"outcome": false,
"reason": "Insufficient transaction history"
}
] |
Each exit condition contains the same attributes:
Attribute | Description |
|---|---|
| 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. By convention, the exit condition sub-rule references are prefaced with an 'x'. |
| The configuration file defines whether the result delivered by the rule processor is flagged as either Exit conditions are usually non-deterministic. |
| The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. |
| Info |
|---|
The |
The configuration object - rule results
While the parameters and exit conditions may be optional for a specific rule processor, the core function and output of a rule processor is contained in the results object. Rule processors offer two different kinds of rule results:
Banded results, where the result from the rule processor is categorized into one out of a number of discrete bands that partition a contiguous range of possible results.
...
Cased results, where the result from the rule processor is an explicit value from a list of discrete and explicit values.
...
The rule processor’s core purpose is to produce a definitive deterministic result based on its programmed behavioral analysis of historical data. The rule configuration defines the bands or values for which rule results can be provided.
...
It is extremely important that the configuration of a rule processor does not leave any gaps in the results, whether banded or cased. Every possible outcome of a rule result must be accounted for, otherwise the rule processor may deliver a result that the typology processor cannot interpret. In the event that a rule processor result misses the configured results, the rule processor will issue an error (.err) result with a reason description of Value provided undefined, so cannot determine rule outcome.
Rule results - banded results
Banded results are partitions in a contiguous range of results, effectively from -∞ to +∞. When a target value is evaluated against a result band the lower limit of a band is always evaluated with the >= operator and the upper limit is always evaluated with the < operator. This way, we can configure the upper limit of one band and the lower limit of the next band with the exact same value to make sure there is no overlap between bands and also no gap.
...
Where a lower limit is not provided, the rule processor will assume the intended target lower limit is -∞.
Where an upper limit is not provided, the rule processor will assume the intended target upper limit is +∞.
A rule processor with a banded results configuration can have an unlimited number of specified bands.
The rule result bands are specified in the config object in the rule configuration as an array of elements under a bands object:
| Code Block |
|---|
"config": {
"bands": [
{
"subRuleRef": ".01",
"upperLimit": 86400000,
"outcome": true,
"reason": "Account is less than 1 day old"
},
{
"subRuleRef": ".02",
"lowerLimit": 86400000,
"upperLimit": 2592000000,
"outcome": true,
"reason": "Account is between 1 and 30 days old"
},
{
"subRuleRef": ".03",
"lowerLimit": 2592000000,
"outcome": true,
"reason": "Account is more than 30 days old"
}
]
} |
Each rule result band contains the same information:
Attribute | Description |
|---|---|
| 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. |
| This attribute defines the lower limit of the band range and is evaluated inclusively ( Where a lower limit is not provided, the rule processor will assume the intended target lower limit is -∞. Unless the very first result band in a configuration has a clear and unambiguous lower limit, it is often omitted. |
| This attribute defines the upper limit of the band range and is evaluated exclusively ( Where an upper limit is not provided, the rule processor will assume the intended target upper limit is +∞. Unless the very last result band in a configuration has a clear and unambiguous upper limit, it is often omitted. |
| 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. |
One of the most frequent limit values in use in the platform is based on time-frames. In the platform, all time-frames and associated limits are represented in milliseconds. The following table reflects the conventional milliseconds for different time terms in our configurations:
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-specific 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 a typology-specific configuration is used to formulate the scenario.
A typology processor configuration document typically contains the following information:
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
Typology configuration metadata
The typology configuration “header” contains metadata that describes the typology. The metadata includes the following attributes:
ididentifies the specific typology processor and version related to the configuration. There will typically only be a single typology processor active in the platform at a time, but it is possible and conceivable that multiple typology processors and/or versions can co-exist simultaneously.cfgis the unique version of the typology configuration. Though unlikely, multiple different versions of a typology configuration can co-exist simultaneously in the platform.descoffers a readable description of the typology
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.
...
Every. Possible. Outcome.
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:
Attribute | Description |
|---|---|
| The rule processor that was used to determine the rule result is uniquely identified by this identifier attribute. |
| The configuration version attribute specifies the unique version of the rule configuration that was used by the processor to determine this result. |
| 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 unique outcome is defined by a unique sub-rule reference identifier to differentiate the delivered outcome from the others The unique combination of |
| The outcome of the rule result will be either true or false, depending if the configurer expected the result to deterministic or not. If the outcome is true, the rule result will be assigned the weighting associated with the |
| The outcome of the rule result will be either true or false, depending if the configurer expected the result to deterministic or not. If the outcome is false, the rule result will be assigned the weighting associated with the |
The expression object
3. Version Management
3.1. Introduction and Basics
...