...

Because the rules object contains every possible rule result outcome from each of the rule processors allocated to the typology, the typology configuration can become quite verbose, but here’s a short example of a rules object for a typology that contains two rules:

The expression object

The expression object in the typology processor defines the formula that is used to calculate the typology score. The expression is able to accommodate any formula composed out of a combination of multiplication (*), division (/), addition (+) and subtraction (-) operations.

In its most basic implementation, the expression is merely a sum of all the weighted rule results. This also means that every deterministic rule listed in the rules array object in the typology configuration must be represented in the expression as a term, otherwise the rule weighting will not be taken into account during the score calculation.

The expression object contains the operators and terms that make up the typology scoring formula. Operators and their associated terms are defined as a series of nested objects in the JSON structure. For example, if wanted to add two terms, a and b, I would start the expression with the operator and then nest the terms beneath it, as follows:

a + b

"expression": {
  "operator": "+",
  "terms": ["a", "b"]
}

In the platform the terms a and b would be represented by their unique id and cfg combination:

{
  "rules": [
  {
    "id": "001@1.0.0",
    "cfg": "1.0.0",
    "ref": ".err",
    "true": 0,
    "false": 0
  },
  {
    "id": "001@1.0.0",
    "cfg": "1.0.0",
    "ref": ".x01",
    "true": 100,
    "false": 0
  },
  {
    "id": "001@1.0.0",
    "cfg": "1.0.0"
}

We don’t have to also supply a specific sub-rule reference: each rule processor only submits one of its possible rule results at a time.

If, for example, we wanted to apply an additional multiplier to the formula (e.g. (a + b) * c, the resulting expression would be structured as follows:

"expression": {
  "operator": "*",
  "terms": ["c,
    "ref": ".01",
    "true": 200,
    "false": 0
  },
  {
    "id": "001@1.0.0",
    "operatorcfg": "+1.0.0",
    "termsref": ["a.02",
"b"]   ] }

By example, a complete expression for a typology that relies on 4 rule results and calculates the typology score as a sum of the rule result weightings would be composed as follows:

"expression"true": {100,
  "operator": "+",   "termsfalse": 0
[  },
  {

     "id": "001@1002@1.0.0",
 
    "cfg": "1.0.0",
    } "ref": ".err",
    {
 "true": 0,
    "idfalse": 0
  },
  {
    "id": "002@1.0.0",
 
    "cfg": "1.0.0"
    },
    {
"ref": ".x01",
     "idtrue": "003@1.0.0"100,
      "cfgfalse": "1.0.0"
 
  },
    {
      "id": "004@1002@1.0.0",
 
    "cfg": "1.0.0",
    }, "ref": ".x02",
    "true": 100,
    "false": 0
 ]
}

Mathematically, this expression would translate to:

...

or simply:

typology score = rule 001 weighting + rule 002 weighting + rule 003 weighting + rule 004 weighting

The workflow object

The workflow object determines the thresholds according to which the typology processor will decide if an action is necessary in response to the typology score. A typology can be configured with two separate thresholds:

Alert (alertThreshold): this threshold will only alert an investigator if the threshold was breached, but will not force the typology processor to take any other direct action

Interdiction (interdictionThreshold): if breached, this threshold will force the typology processor to issue a message to the client platform to block the transaction. This action will also force an alert to an investigator at the end of the evaluation process.

A threshold breach occurs when the calculated typology score is greater or equal to the threshold (>=).

Alerts are intended to trigger the investigation of a transaction; either because the transaction was blocked by interdiction, or perhaps because there was not sufficient evidence to outright block a transaction, but enough evidence was accumulated to arouse suspicion.
A typology may be configured with alert threshold, but without an interdiction threshold, usually when the typology is focused on money laundering and the intention of the alert is to trigger surveillance processes without tipping the participants off that their criminal behavior had been noticed.

The platform also allows for separate thresholds for alerts and interdictions so that the platform can generate an alert for a lower and more sensitive threshold than an interdiction. The platform may also omit the alert threshold altogether since the interdiction threshold will generate an alert anyway if the interdiction threshold is breached. (And even though it is possible to specify an alert threshold greater or equal to an interdiction threshold, this alert threshold would be redundant.)

If a specific type of threshold is not required, the threshold should be omitted entirely. A typology configuration threshold value of 0 (zero) will always result in a breach of that typology.

The thresholds are located in a workflow object in the typology configuration. If, for example, the platform is expected to alert on a typology score of 500 or more, and interdict on a typology score of 1000 or more, the workflow object would be composed as follows:

"workflow": {
  "alertThreshold": 500,
  "interdictionThreshold": 1000
} },
  {
    "id": "002@1.0.0",
    "cfg": "1.0.0",
    "ref": ".01",
    "true": 100,
    "false": 0
  },
  {
    "id": "002@1.0.0",
    "cfg": "1.0.0",
    "ref": ".02",
    "true": 200,
    "false": 0
  }
]

The expression object

The expression object in the typology processor defines the formula that is used to calculate the typology score. The expression is able to accommodate any formula composed out of a combination of multiplication (*), division (/), addition (+) and subtraction (-) operations.

In its most basic implementation, the expression is merely a sum of all the weighted rule results. This also means that every deterministic rule listed in the rules array object in the typology configuration must be represented in the expression as a term, otherwise the rule weighting will not be taken into account during the score calculation.

The expression object contains the operators and terms that make up the typology scoring formula. Operators and their associated terms are defined as a series of nested objects in the JSON structure. For example, if wanted to add two terms, a and b, I would start the expression with the operator and then nest the terms beneath it, as follows:

a + b

"expression": {
  "operator": "+",
  "terms": ["a", "b"]
}

In the platform the terms a and b would be represented by their unique id and cfg combination:

{
  "id": "001@1.0.0",
  "cfg": "1.0.0"
}

We don’t have to also supply a specific sub-rule reference: each rule processor only submits one of its possible rule results at a time.

If, for example, we wanted to apply an additional multiplier to the formula (e.g. (a + b) * c, the resulting expression would be structured as follows:

"expression": {
  "operator": "*",
  "terms": ["c",
    "operator":"+",
    "terms": ["a", "b"]
  ]
}

By example, a complete expression for a typology that relies on 4 rule results and calculates the typology score as a sum of the rule result weightings would be composed as follows:

"expression": {
  "operator": "+",
  "terms": [
    {
      "id": "001@1.0.0",
      "cfg": "1.0.0"
    },
    {
      "id": "002@1.0.0",
      "cfg": "1.0.0"
    },
    {
      "id": "003@1.0.0",
      "cfg": "1.0.0"
    },
    {
      "id": "004@1.0.0",
      "cfg": "1.0.0"
    },    
  ]
}

Mathematically, this expression would translate to:

...

or simply:

typology score = rule 001 weighting + rule 002 weighting + rule 003 weighting + rule 004 weighting

The workflow object

The workflow object determines the thresholds according to which the typology processor will decide if an action is necessary in response to the typology score. A typology can be configured with two separate thresholds:

Alert (alertThreshold): this threshold will only alert an investigator if the threshold was breached, but will not force the typology processor to take any other direct action

Interdiction (interdictionThreshold): if breached, this threshold will force the typology processor to issue a message to the client platform to block the transaction. This action will also force an alert to an investigator at the end of the evaluation process.

A threshold breach occurs when the calculated typology score is greater or equal to the threshold (>=).

Alerts are intended to trigger the investigation of a transaction; either because the transaction was blocked by interdiction, or perhaps because there was not sufficient evidence to outright block a transaction, but enough evidence was accumulated to arouse suspicion.
A typology may be configured with alert threshold, but without an interdiction threshold, usually when the typology is focused on money laundering and the intention of the alert is to trigger surveillance processes without tipping the participants off that their criminal behavior had been noticed.

The platform also allows for separate thresholds for alerts and interdictions so that the platform can generate an alert for a lower and more sensitive threshold than an interdiction. The platform may also omit the alert threshold altogether since the interdiction threshold will generate an alert anyway if the interdiction threshold is breached. (And even though it is possible to specify an alert threshold greater or equal to an interdiction threshold, this alert threshold would be redundant.)

If a specific type of threshold is not required, the threshold should be omitted entirely. A typology configuration threshold value of 0 (zero) will always result in a breach of that typology.

The thresholds are located in a workflow object in the typology configuration. If, for example, the platform is expected to alert on a typology score of 500 or more, and interdict on a typology score of 1000 or more, the workflow object would be composed as follows:

"workflow": {
  "alertThreshold": 500,
  "interdictionThreshold": 1000
}

2.3. The Network Map

Introduction

The network map associates a specific transaction type with the rules and typologies that will be used to evaluate the incoming transaction. The network map allows for a sub-division of typologies according to themes (channels) as may be appropriate for a specific implementation. For example, typologies can be arranged according to the types of financial crime they aim to detect, or the speed and performance with which they are required to respond, based on the infrastructure onto which the rules are deployed.

The network map is structured as a decision tree that defines the rules in a typology, the typologies into a channel and the channels into a transaction (by type):

...

The network map contains the following information:

• Network map metadata

• A messages object that contains

  • an array of transactions, containing

    • an array of channels, containing

      • an array of typologies, containing

        • an array of rules

The network map allows the Channel Router and Setup Processor to:

1. Identify whether the incoming transaction type should be routed for evaluation (undefined types are not routed at all)

2. Determine which typologies will be used to evaluate the transaction

3. Determine which unique rules are required by those typologies

4. Route the transaction to each of the identified rules

The network map defines the route in a hierarchy following the order transactions > channels > typologies > rules and the evaluation is executed along the defined route in reverse order: rules > typologies > channels > transaction.

Network map metadata

The network map “header” contains metadata that describes the network map. The metadata includes the following attributes:

• cfg is the unique version of the network map. The version allows an investigator or auditor to know which version of the network map was used in a specific evaluation.

• active is a flag that identifies the current active network map in use by the platform. There can only ever be one active version of the network map and this flag is updated when a network map is superseded by a new version. The value of this attribute for the current active network is true. The value for every inactive version is false.

The messages object

The messages object is an array that contains information about the transactions that the platform is expected to evaluate. Each element in the messages object contains the following attributes:

• id is the unique identifier for the Transaction Aggregation and Decisioning Processor (TADProc) that will be used to ultimately conclude the evaluation of a specific transaction. It is possible for a transaction to be routed to a unique TADProc that contains specialized functionality related to summarizing the transaction’s results¹⁰.

• cfg is the unique version of the deployed TADProc that will be used to conclude the evaluation of the transaction.

• host defines the NATS subscription queue for the TADProc where the results of the previous processor in the evaluation flow, the typology processor, will be published. When there is only a single TADProc deployed, the default value of “NATS Server” is used.

• txTp defines the transaction type for which the message element is intended. The txTp value here must match a corresponding TxTp attribute in the root of the incoming message. If no matching txTp attribute is found in the network map, the transaction will not be routed for evaluation and will simply be ignored by the CRSP.

• channels defines the next layer of evaluation destinations along the route laid out by the network map for the evaluation.

The channels object is a nested array object inside the transaction element in the messages array object. The channels array defines the channels within which the typologies are distributed and contains the following information. The channel object contains id and cfg attributes, but these are no longer relevant in the platform and will shortly be removed; until then, the attributes must be populated, but the values are irrelevant. It should also be noted that the platform is deployed by default to only contain a single channel.

The only attribute in the channels array that still has any bearing on platform behavior is the typologies object array that specifies all the typologies that are collected in the specific channel.

The typology object array contains the following attributes:

• id is the unique identifier for the typology that will be . It is possible for a transaction to be routed to a unique TADProc that contains specialized functionality related to summarizing the transaction’s results¹⁰.

• cfg is the unique version of the deployed TADProc that will be used to conclude the evaluation of the transaction.

• host defines the NATS subscription queue for the TADProc where the results of the previous processor in the evaluation flow, the typology processor, will be published. When there is only a single TADProc deployed, the default value of “NATS Server” is used.

• txTp defines the transaction type for which the message element is intended. The txTp value here must match a corresponding TxTp attribute in the root of the incoming message. If no matching txTp attribute is found in the network map, the transaction will not be routed for evaluation and will simply be ignored by the CRSP.

• channels defines the next layer of evaluation destinations along the route laid out by the network map for the evaluation.

As with the definition of other processors in the network map, the elements of the typologies object array contains id and cfg attributes to define the specific typology processor¹⁰ and version that will be used to evaluate a particular typology for the transaction, as well as the NATS subscription queue for the typology processor where the results of the previous processors in the evaluation flow, the rule processors, will be published. In full, t

"typologies": [
  {
    "id": "001@1.0.0",
    "cfg": "1.0.0",
    "host": "NATS Server",
    "rules": [
       ...
    ]
  }
]

3. Version Management

3.1. Introduction and Basics

...

1. 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.

2. 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.

3. https://frmscoe.atlassian.net/wiki/spaces/FRMS/pages/76906497/Configuration+management#References%3A

4. https://frmscoe.atlassian.net/wiki/spaces/FRMS/pages/6586489/Rule+Processor+Overview#4.1.-Read-rule-config

5. https://frmscoe.atlassian.net/wiki/spaces/FRMS/pages/1740494/Typology+Processing#5.5.-Read-typology-configuration

6. https://frmscoe.atlassian.net/wiki/spaces/FRMS/pages/6259944/Transaction+Aggregation+and+Decisioning+Processor+TADProc#7.4.2.-Read-transaction-configuration

7. https://frmscoe.atlassian.net/wiki/spaces/FRMS/pages/6520927/Channel+Router+and+Setup+Processor+CRSP#3.1.-Read-Network-Map

8. 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.

9. We have found during our performance testing that the text-based descriptions in our processor results undermines the performance gains we achieved with our ProtoBuff implementation. We will be removing the unabridged reason and processor descriptions from the configuration documents in favor of shorter look-up codes that will then also be used to introduce regionalized/language-specific descriptions.

10. In its default deployment, the platform contains a single version of the “core” platform processors (the typology processor and TADProc) at a time. Though it is possible to deploy and maintain multiple parallel versions of these processors and manage routing to these processors through the network map, this guide will only focus on singular core processors for now.