Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
alert-icon-red-11.pngImage Added

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:

Code Block
{
    "id": "018@1.0.0",
    "cfg": "1.0.0",
    "config": {
        "timeframes": [
            {
                "threshold": 7889229000
            }
        ],
        "bands": [
            {
                "subRuleRef": ".00",
                "outcome": false,
                "reason": "Insufficient transaction history"
            },
            {
                "subRuleRef": ".01",
                "lowerLimit": 0,
                "upperLimit": 1.5,
                "outcome": true,
                "reason": "Exceptionally large outgoing transfer detected"
            },
            {
                "subRuleRef": ".02",
                "lowerLimit": 1.5,
                "outcome": true,
                "reason": "Outgoing transfer within historical limits"
            }
        ]
    }
}

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:

Code Block
{
  "id": "078@1.0.0",
  "cfg": "1.0.0",
  "config": {
    "case": [
      {
        "subRuleRef": ".01",
        "value": "WITHDRAWAL",
        "outcome": true,
        "reason": "The transaction is identified as a cash withdrawal"
      },
      {
        "subRuleRef": ".00",
        "outcome": false,
        "reason": "The transaction type is non-indicative for this typology"
      }
    ]
  }
}

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”.)

...