In SAS Visual Investigator, an alert is simply an object that’s used to capture and manage surveillance data for another object. For example, an alert could be generated on an insurance policy that’s related to an abnormal number of claims within a given time period, or on a banking customer whose transactions follow a prescribed pattern.
Alerts are a core component of SAS Visual Investigator. As such, it’s worthwhile diving further into them. This blog post is part one of a series dedicated to alerts in SAS Visual Investigator. In this blog, I will introduce the key alert concepts and terminologies that are unique to SAS Visual Investigator, together with how they are related to one another.
There are several key concepts associated with alerts in SAS Visual Investigator and they are:
Before I go over each concept in greater detail, I want to mention that Scenario Admin is one of three ways to generate alerts in SAS Visual Investigator. Alerts can also be brought into SAS Visual Investigator from external systems, which is often necessary for customers transitioning from another alert management platform. The SAS VI Alerts API allows for the creation of scenario-fired events and alerting events using rest calls and can be wired up to any system of choosing. For more information on the Alert API, check out Visual Investigator Alerts.
Lastly, alerts can also be generated manually by investigators when they deem necessary.
Scenarios are sets of logics and rules used to detect anomalies and suspicious behaviors. There are four scenario types that can be created in SAS Visual Investigator through Scenario Administrator:
To learn more about different types of scenarios, check out my previous blogs on this topic:
When the conditions specified in a scenario is met, the scenario fires. This results in the creation of a scenario-fired event. These events describe the circumstances that triggered the scenario. All the scenario-fired events associated with a given alerting event will appear in the scenario-fired events table on the Alert Activity tab of the Alert Details page. You have the option to rate the productivity of each scenario-fired event, as well as to suppress a scenario.
Scenario-fired events result in the creation of an alerting event, which acts as predecessor to the creation of a new alert if one doesn’t already exist for the given actionable entity, or the update of the existing alert. Alerting events have their own scores, which appear on the alert list, as well as the alert scorecards. For each individual alert, its alerting events can be found on the Alert Activity tab of the Alert Details page.
Additionally, on the Alert Details tab of the Alert Details page, the alerting events and their associated alerting event scores are displayed.
Alerts are always tied to other objects and these objects, or entities, are known as actionable entities. When an alert is generated on an insurance policy because the policy has abnormal connections to insurance claims, the actionable entity is the policy. Another example is in the world of banking, where an alert might be generated on a banking customer whose transactions fall into a particular pattern that’s indicative of fraudulent behavior. In this case, the banking customer is the actionable entity.
On the Alerts page, you can find the actionable entity for each alert in the alert table.
Now that I’ve outlined the key alert concepts, it’s worthwhile to examine how they are related to one another. Below is a graphical representation of their relationships.
Scenarios make up the base of the relationship tree. When the business logic detailed in these scenarios are met, the scenarios fire and trigger scenario-fired events. The scenario-fired events describe the events that caused the scenario to fire. These scenario-fired events then lead to the creation of an alerting event. An alerting event can be the result of one scenario-fired event or multiple scenario-fired events. The alerting events lead to the creation of a new alert or the update of existing alert. Lastly, alerts are always tied to actionable entities.
If we were to apply a simplified example to explain these alert concepts, we can imagine Santa Claus as the end user of SAS Visual Investigator, whose objective is to determine whether a child belongs on the naughty list.
In this case, the actionable entities will be the children on the receiving end of Santa’s evaluation. The scenarios are the rules that Santa uses to determine the naughtiness of each child. When a child commits an action that’s been outlined in Santa’s scenarios, such a not doing their homework, that results in a scenario-fired event. From this one naughty action (one scenario-fired event) or multiple naughty actions (multiple scenario-fired events), alerting events are generated, which essentially raises an alert on the child. It is then up to the end user, Santa, to review, triage and disposition these alerts to determine who will not be receiving gifts this holiday.
Hope this example helped you better understand these SAS Visual Investigator alert concepts.
This blog post is part one of a blog series dedicated to SAS Visual Investigator alerts. In this blog, we talked about the alert concepts unique to SAS Visual Investigator and how they are related to one another. Stay tuned for future topics on SAS Visual investigator alerts and more!
For additional content on SAS Visual Investigator, check out the following blog posts:
Dive into keynotes, announcements and breakthroughs on demand.
Explore Now →The rapid growth of AI technologies is driving an AI skills gap and demand for AI talent. Ready to grow your AI literacy? SAS offers free ways to get started for beginners, business leaders, and analytics professionals of all skill levels. Your future self will thank you.