Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 (networkMap or configuration) and collection is via Arango DB’s HTTP API that is deployed as standard during platform deployment.

...

  • 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

...

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.

Example of the rule configuration metadata:

Code Block
{
  "id": "rule-001@1.0.0",
  "cfg": "1.0.0",
  "desc": "Derived account age - creditor",
  ...
  }

The configuration object - parameters

...

Info

Why does the typology configuration cfg look different from the rule configuration cfg?

A rule processor (defined by its id) is closely paired with its configuration (defined by the cfg): the configuration works for that rule processor and no other, and the rule processor won't work with another rule processor's configuration.

A typology processor is a generic “engine” processor. It is not paired with a specific typology the way a rule processor is - it is intended to work for multiple, if not all, typologies. The typology configuration needs another way to reference the specific typology that will be scored by the typology processor. For that reason, the cfg attribute is subdivided in the same way as the id into name and a version parts. And remember we can have multiple parallel typology processors if we need them, so the id describes the specific typology processor and its version (for routing purposes), and the cfg describes the specific typology and the version of its configuration.

Example of the typology configuration metadata:

Code Block
{
  "id": "typology-processor@1.0.0",
  "cfg": "typology-001@1.0.0",
  "desc": "Use of several currencies, structured transactions, etc",
  ...
  }

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.

...

Collection name

Processor Type

configuration

Rule4

typologyExpression

Typologies5

transactionConfiguration

Transaction Aggregation and Decisioning6

...