ATTENTION: This page has been migrated to the Tazama GitHub repository and is now located at: https://github.com/frmscoe/docs/blob/dev/Product/rule-processor-overview.md This page will no longer be maintained in Confluence. |
---|
Table of Contents |
---|
Introduction
The foundation of the Actio Tazama Transaction Monitoring service is its ability to evaluate incoming transactions for financial crime risk through the execution of a number of conditional statements (rules) that render a boolean (True or False) result based on specific attributes of the incoming transaction and past transactions.
...
Atomic Rule: A single logic statement that evaluates to a single outcome. (Think of an atomic rule as a typical “IF” statement with a single term.)
Example:
IF an MSISDN has been associated with a new SIM ICCID within the last 3 days |
In this example, the rule will evaluate directly to either TRUE or FALSE.
Compound rule: The combination of multiple atomic rules through logic operators (AND, OR, XOR) that evaluates to a single outcome.
Example:
IF the Payer is a private individual |
AND
IF the Payer had never performed a transfer request before |
Compound rules are expected to only feature as typologies where the results from several rules are combined into a typology and scored to identify potential financial crime.
...
Rule-set: Multiple mutually exclusive logic statements that are combined to evaluate to a single outcome. (Think of a rule-set as a typical “CASE” statement.)
Example:
IF no transactions had been performed to or from a payee’s account within a given time-frame |
Sub-rule ref | Statement | Outcome | Reason |
.01 | IF the elapsed time since the most recent transfer to or from the account is more than 3 months, but less than 6 months | Payee account dormancy 3 = TRUE | Payee account dormant for between 3 and 6 months |
.02 | IF the elapsed time since the most recent transfer to or from the account is more than 6 months, but less than 12 months | Payee account dormancy 6 = TRUE | Payee account dormant for between 6 and 12 months |
.03 | IF the elapsed time since the most recent transfer to or from the account is more than 12 months | Payee account dormancy 12 = TRUE | Payee account dormant for longer than 12 months |
.00 | IF the elapsed time since the most recent transfer to or from the account is less than 3 months | Payee account dormancy = FALSE | Payee account not dormant in the last 3 months |
.04 | IF no prior transfer requests from or to the account could be found at all | Payee account dormancy = FALSE | Inconclusive payee account dormancy - no transactions found |
In this example, the rule that is evaluated to be TRUE will be identified in the output of the rule. For example, if there had been no transfer requests from or to the account in 211 days, the rules processor will output “Rule 003@1.0.0.02: Payee account dormancy 6 = TRUE”, along with the appropriate reason code.
...
The rule processor will read its default configuration parameters from a configuration file stored in the Actio Tazama Configuration database. A rule processor can be parameterised with the following information:
Time-frames: Time-frames are input parameters that define the scope of a historical query. If a condition is to be evaluated over data accumulated during a specific period, e.g. IF multiple incoming transactions within the last hour show similar or identical values for transaction amounts (within 5%): The time-frame for the evaluation is 1 hour. Timeframes are always specified in Epoch Millis as the lowest common unit of measure for time in the Actio Tazama platform. (See: https://www.epochconverter.com/ ).
Band limits: If a number of rule conditions are evaluated as a rule-set, band limits define the lower and upper bounds of each of the rule bands. In our rule-set example above: IF no transactions had been performed to or from a payee’s account within a given time-frame, the band limits are:
Sub-Rule Ref | Lower limit | Upper limit |
---|---|---|
.00 | 3 months | |
.01 | 3 months | 6 months |
.02 | 6 months | 12 months |
.03 | 12 months |
The configuration for a specific rule will be read from a JSON configuration file stored in the config database.
...
Every rule band evaluates to either a true or false outcome. In general, the true or false outcomes are somewhat arbitrary, but the convention followed in the Actio Tazama platform is that a false outcome is not expected to have a weighted scoring impact on the associated typology score and a true result is expected to have an impact on the typology score.
...
Threshold = 1.5
Time-frame = 3 months
Rule ref | Sub-rule ref | Statement | Outcome | Reason |
018 | .01 | IF the debtor transfers > (maximum amount * threshold) in the timeframe (3 months) | TRUE | Exceptionally large outgoing transfer detected |
018 | .02 | IF the debtor transfers <= (maximum amount * threshold) in the timeframe (3 months) | FALSE | Outgoing transfer within historical limits |
018 | .00 | If no transaction history can be retrieved for the rule | FALSE | Insufficient transaction history |
Translated to a “band” specification, this would be presented as follows:
Rule ref | Sub-rule ref | lower limit | upper limit | Statement | Outcome | Reason |
018 | .01 | 0 | 1.5 | IF the debtor transfers > (maximum amount * threshold) in the timeframe (3 months) | TRUE | Exceptionally large outgoing transfer detected |
018 | .02 | 1.5 | null | IF the debtor transfers <= (maximum amount * threshold) in the timeframe (3 months) | FALSE | Outgoing transfer within historical limits |
018 | .00 | null | null | If no transaction history can be retrieved for the rule | FALSE | Insufficient transaction history |
The representation of this specification in a config file would then be:
|
Example 2 (case):
Rule 078 is an atomic rule that checks if a specific transaction is classified as a “WITHDRAWAL”. The specification of the configuration is presented as follows:
Rule ref | Sub-rule ref | Statement | Outcome | Reason |
078 | .01 | IF the transaction type is “WITHDRAWAL” | TRUE | The transaction is identified as a cash withdrawal |
078 | .00 | IF the transaction type is NOT “WITHDRAWAL” (ELSE) | FALSE | The transaction type is non-indicative for this typology |
The representation of this specification in a config file would then be:
|
4.2. Read historical transactions
Some rules require additional data from transactions that had been processed previously, or even the results from previous evaluations. These rules must be able to retrieve the required information from the transaction history repository/database.
For example, the rule:
IF multiple incoming transactions within the last hour show similar or identical values for the transaction description by calculating the Damerau–Levenshtein distance between the descriptions |
would require all previous transactions routed to a single creditor account within the last hour. (Coincidentally, explicit values for “multiple” and “similar” would be defined through “threshold” parameters, as would an explicit “time-frame” for “within the last hour”.)
...