10. Rules for the automation of processes in digital profiles¶

Note

Unless you are a trak.e expert, you probably can skip this section.

trak.e offers the possibility fo evaluationg generic rules based on the data of a profile, its alerts, its associated documentation and its transaction system. The result of said rule will be impacted in a property of the profile defined by the tenant. It is allows to add any number of generic rules, but at most 50 can be active at the same time.

10.1 Events¶

Generic rules are configured to be executed upon different trak.e events. Each rule can be configured to run upon one or more events. The possible events that trigger a rule are the following:

New profile
Profile update
New alert
Alert update
New document
Document update
Document deletion
New transaction

When the rule is triggered by an update event, you should also specify which field change triggers the update. Any property in the top-level of the matching entity can be used.

For example, if we aim to create a rule that executes whenever a profile changes its risk, we can use the following trigger:

...
"triggers": [
  {
  "event": "dprofile",
  "operation": "update",
  "field": "risk"
  }
]
...

10.2 Implementation¶

The rules follow the scheme seen for risk matrix and the assessment of transactional profile: rules written in Python language.

10.2.1 Parameters¶

The available variables are:

profile: When evaluating a rule, the profile variable is put into the execution context. This variable contains the digital profile that is currently being processesed. All the attributes detailed in the section Digital Profiles are available in this object.
alerts: When evaluating a rule, the alerts variable is put into the execution context. This variable contains both open and closed alerts of the profile that is currently being processed. The variable is an array where each element is an object representing an alert. All the attributes detailed in the section Alerts are available in this object.
documents: When evaluating a rule, the documents variable is put into the execution context. This variable contains all the documents currently associated with the profile. The variable is an array where each element is an object representing a document. All the properties detailed in the section Documentation ara available in this object.
hist_trxs: You can access the history of transactions of the digital profile under this name. The variable is put into the execution context as a pandas.DataFrame. Each row of the DataFrame represents a transactions and the columns of the dataframe are the properties of the transactions (using an underscore as a separator in case of nested properties). You may have an empty history of transactions (no rows and no columns) - if the digital profile does not record transactions
transaction: When evaluating the rule the transaction variable is put into the execution context. This variable contains the transaction associated with the profile that is currently being processed.

10.2.2 Rule result¶

The rule must define a variable with name ASSESSMENT_VALUE which value will be later impacted in the profile in the attribute defined in profile_json_path. The profile_json_path must be JSONPath to attribute of the profile where you need to impact the value. If the property should existe, this will be updated. Should the attribute not exist, it will be created.

As a basic example, if the rule has profile_json_path: $.metadata.age set, and the execution of the rule determines that ASSESSMENT_VALUE: 43 for some profile, the property age will be created or update inside the metadata object of the profile (this is, inside the additional information).

It is not necessary that the attribute to be updated is part of the additional information, predefined fields can also be updated. For example, a rule that writes the state field can be used to define automatic transitions between file states under customer-defined business rules.

Note

Some attribute of the profile can't be updated automatically. They include: - identifier (id). - version number (version). - creation and modification timestamps and users (created_at, modified_at, created_by, modified_by). - Tax payer identified (tax_payer_id). - external reference number (external_ref). - cabinet that holds the profile documentation (documents). - last watchlists check, risk, last risk assessment, transactional profile and last transactional profile assessment (blacklists_checked_at, transactional_profile_amount, transactional_profile_calculated_at, risk, risk_calculated_at). - type of person (legal person or natural person) (person_type).

Note

Context: In addition to the values used to interpret the evaluation of the rule and that will eventually be impacted in the file, the context of the evaluation is returned, particularly those defined public variables. This allows values calculated during the execution of the rule to be saved and made available when viewing the results.

10.3 Rule testing¶

Trak.e allows you to test the rule before saving it with any database profile or with an as-needed profile to test edge cases and make sure the rule is correct both syntactically and semantically.

10.4 Name and description¶

The rule is saved with a name, which must be unique. The rule also allows to attach a description in rich text format.

10.5 Example: Update information in lists¶

The following process automation rule keeps the watchlists information in the digital profile consistent with the analysis made by the operators of the alerts of the profile. While an alert is in progress, the hit is kept open but unacknowledged. When closing, it is decided: if the analyst has confirmed the hit, it marks it as confirmed in the profile aswell, and if they has not confirmed it, it discards the hit completely. This is just an example - it can be adapted to the needs of each entity.

blacklist_info = profile.blacklist_found
if blacklist_info is None:
     blacklist_info = {}
for alert in alerts:
     incident_state = alert.state
     incident_type = alert.incident_type
     if "blacklist_hit" in incident_type:
         match_type = alert["info"]["match_type"]
         confirmed = alert["info"]["confirmed"]
         if incident_state == "open":
             blacklist_info[match_type] = {}
             blacklist_info[match_type]["hit"] = True
             blacklist_info[match_type]["confirmed"] = False
         elif incident_state in ("in_progress", ):
             blacklist_info[match_type] = {}
             blacklist_info[match_type]["hit"] = True
             blacklist_info[match_type]["confirmed"] = False
         elif incident_state in ("closed", "reported"):
             if confirmed:
                 blacklist_info[match_type] = {}
                 blacklist_info[match_type]["hit"] = True
                 blacklist_info[match_type]["confirmed"] = True
             else:
                 blacklist_info.pop(match_type, None)

k=None
v=None
blacklist_info = { k: v for k,v in blacklist_info.items() if v }

ASSESSMENT_VALUE = blacklist_info

The rule is configured with the profile_json_path in $.blacklist_found.

The rule is configured with the following triggers:

     ...
     "trigger": [
         {
             "event": "incident",
             "operation": "add",
             "field": null
         },
         {
             "event": "incident",
             "operation": "update",
             "field": "state"
         },
         {
             "event": "incident",
             "operation": "update",
             "field": "info"
         },
         {
             "event": "incident",
             "operation": "update",
             "field": "confirmed"
         }
     ],

This indicates each time a new alert is added, or each time its status, information, or "confirmed" field is updated.

10.6 API¶

For technical information on the API to create, search and modify generic rules, the API documentation is available.