5. Alerts¶

Another of Trak.e's services is called Alerts. This service mainly specifies the representation of an alert.

At Trak.e, alerts are used to report insights, related to natural or legal persons, which back-office operators must analyze and eventually take necessary measures. Among the types of alerts, we can name: hits on sanction lists, terrorists, as well as high risk calculation alerts. The service also allows to create alerts manually.

5.1 Alert properties¶

The service represents an alert with a set of property. The most important properties are detailed as following:

• dprofile_id: unique identifier of the digital profile that triggered the alert.
• user_id: unique identifier of the user that has been assigned to the alert.
• title: Alert title.
• incident_type: Alert type (e.g. hit in PEP list).
• state: State of the alert (e.g. open, closed, in progress).
• severity: Severity of the alert (e.g. high, medium, low). The alerts are created with a default severity that can be configured by alert type, or even by rule for those alerts created as the result of a rule of transactional monitoring or profile monitoring
• priority: Priority of the alert (e.g. high, medium, low). The alerts are created with a default priority that can be configured by alert type, or even by rule for those alerts created as the result of a rule of transactional monitoring or profile monitoring
• due_date: Due date of the alert. he alerts are created with a default priority that can be configured by alert type.

5.1.1 Labels/Tags¶

An alert can be marked using arbitrary strings as tags. A label has a minumum length of 2 characters and a maximum of 20 characters.

5.1.2 Alert Merger¶

Trak.e allows merging alerts within the application. It should be noted that when alerts are grouped, the individual record of each alert within the application is lost. This merging of alerts can be manual or automatic based on certain parameters.

The automatic alert merging is implemented with a set of parameters.

There can only be one set of parameters active at any time. The parameters are the period and a merging condition. The period refers to the range in which you want the alerts to be merged (it can be within 1 hour, day, week or month). The merging condition can be by alert type, by rule name (i.e. the rule that triggered an alert) or always, which groups any type of alert.

5.1.3 Alert Types¶

Trak.e offers a default set of alert types:

• adverse_news_blacklist_hit: The profile was found on an adverse news monitoring list.
• obligated_subject_blacklist_hit: The profile has been found on a monitoring list of supervised entities/institutions.
• pep_blacklist_hit: The profile was found on a monitoring list of politically exposed persons.
• sanctioned_blacklist_hit: The profile was found on a sanctions list (example: OFAC).
• terrorist_blacklist_hit: The profile was found on a terrorism list.
• wanted_blacklist_hit: The profile was found on a wanted list, for example, on the lists published by the FBI or by Interpol.
• other_blacklist_hit: profile was found on a watchlist - when no more specific type applies.
• trx_aml_alert: The profile exhibits an unusual transactional behavior, due to its number, quantity or characteristics, it does not fall within the system and normal practices of a business, an industry or a specific sector. These alerts must be reviewed by analysts for the prevention of money laundering and financing of terrorism or by risk analysts to determine if it is suspicious and take the corresponding actions if it were the case.
• trx_fraud_alert: The profile exhibits transactional behavior that makes it suspicious of being involved in fraudulent use of the system.
• trx_normative_alert: The profile exhibits transactional behavior that, without being unusual or suspicious, should be reviewed by a backoffice analyst.
• doc_due: A document in this profile has reached its expiration date.
• doc_missing: A document is missing from this profile that was marked as required following some profile monitoring business rule.
• doc_notice: A document in this profile is about to expire.
• due_diligence: Ongoing due diligence should be carried out on this profile to ensure that the documents, data and information collected within the KYC process are kept up-to-date and relevant.
• high_risk: The profile has high risk, or has experienced an unusual increase in its risk scoring.
• other: Generic type for other types of alert not contemplated.

In addition to including a generic type for manual alerts, trak.e offers the ability to create new types of alerts to meet the needs of the organization.

5.1.4 Additional Information¶

Each type of alert contains specific additional information that depends on the type of alert we are dealing with. For example, for transactional monitoring alerts for fraud, the transaction that caused the alert to be triggered is included.

For tenant-created alert types, additional information about the alert in key-value format can be saved to the alert. Trak.e allows each client to configure in a json schema¹ the structure of this additional information. This specification will allow validation and standardization of the additional information. Unlike the profiles, the additional information in the alerts differs from one another due to the type of incident, so a json schema must be defined for each type.

For example if an alert of type custom_trx_alert contains additional information about the transaction we can define:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/product.schema.json",
  "title": "Trx fraud alert",
  "description": "Additional info on the alert",
  "type": "object",
  "properties": {
    "transaction_info": {
      "description": "Additional info on the transaction",
      "type": "object",
      "properties": {
        "transaction_type":{
          "type": "string",
        },
        "ref":{
          "type": "string",
        },
        "timestamp":{
          "type": "integer"
        }
      }
    }
  }
}

After defining the schema, we can save and access the information in the alert using the info.transaction_info attribute. It should be noted that in the absence of a schema, additional information can also be saved in the alert, but no validation will be performed nor will it support manual input.

5.2 Workflows¶

The alerts have an attribute that specifies in which state they are in. The default states of trak.e are:

• Open (open): The alert is yet to be treated.
• In Progress (in_progress): The alert is being treated.
• Closed (closed): The alert has been closed.

You can additionally define all the states that the entity considers necessary. Each entity can implement the workflow that best suits their needs.

5.2.1 Default Workflow¶

Trak.e has a default alert status workflow that can be tailored to the needs of each client.

graph TD
  open --> in_progress
  in_progress --> open

  open --> closed
  closed --> open

  closed --> in_progress
  open --> in_progress

As explained in the Digital Profile Workflow, each transition has a source and destination nodes representing the current state and the desired states respectively. In addition, it may have a condition that has to be met in orden to execute the transition (condition). The available states after a given states depends on the transitions and the conditions that are assessed in that moment.

The condiitions have two arguments, the current alert and the security context of the current operator. The condition must be a valid Python expression.²

Python dict objects may be accessed with Javascript dot syntax, in case of missing key the field None value would be returned.

The alert contains all the information discussed above.

The security context includes the property scope, that is a list of the scopes of the user/application that is using trak.e. In that way, we can define, for example, that only users with scope AML Supervisor can transition from in_progress to closed.

5.3 Comments¶

Each user of Trak.e Web can add comments to the alert that you consider relevant. These comments are in rich text format. The comments are linked to the user who made them. In addition, the date and hour of the comment is saved. A user may edit or delete the comment that they have made, but can only see comments made by other people. The uses with the "Watcher" scope can see all the comments, but can't add new comments.

5.4 Documentation¶

Each user of Trak.e Web may add documents to the alert that you consider relevant.

5.5 Resources¶

5.6 API¶

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