Aggregation Scenarios and Entity Relationships in SAS Visual Investigator

One of the most powerful features of SAS Visual Investigator is its scenario authoring capability. It allows administrators to build scenarios using organization-specific business rules to detect anomalies, potentially stopping illicit activities in their tracks.

The different types of scenarios supported by SAS Visual Investigator are as follows:

Record-level Scenario: Evaluates the data by individual records
Aggregation Scenario: Evaluates the data at an aggregated level
DATA Step Scenario: Uses SAS DATA step code and SAS macro language to create a truly bespoke scenario
Summary scenario: Uses the scenario-fired events generated by primary scenarios as input data and applies rules to that data to generate a final outcome.

Once an alert flow has been created and the desired data sources have been loaded, the new scenario dropdown menu on the flow page can be used to create a new scenario:

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

However, sometimes you may find that the Aggregation scenario menu option is grayed out.

This is because the appropriate relationship hasn’t been configured between the relevant entities. This post aims to help you navigate this issue with a worked example.

Example Scenario for Insurance Fraud

The desired behavior that we wish to capture is a situation where multiple insurance claims are filed against a single insurance policy. In the network diagram below, policy is represented by the blue document icon and claim is represented by the orange document icon. As illustrated, multiple claims are attached to the single policy. This pattern of losses might suggest that the policy holder is intentionally exploiting the system—a behavior worth further investigation.

Prerequisites

In order to build this particular scenario, three pre-requisites must be met:

The appropriate source table must be loaded. In this case, the source table is the table holding the insurance claims data. Within this table, there must be an association between claims and policies such that we can group by the common policy number and count the number of claims filed against it. See below for an example of the data.

Table 1: Mock auto claim data

Claim ID	Policy ID	…
1001	100	…
1002	200	…
1003	300	…
1004	300	…
1005	300	…
1006	400	…

In the above example, there are three claims filed against the policy with the Policy ID of 300. This is the behavior we wish to flag.

This data source can be added to the alert flow by simply navigating to the Data Sources section of the flow page and using the Add data sources button.

There must be a configured and reindexed relationship between the actionable entity and the source data. As illustrated in the previous prerequisite, there is a clear data relationship between claim and policy in the source table auto_claim. It is evident that this relationship is many-to-one, as in multiple claim records could share a common Policy ID value. This relationship must be correctly configured in SAS Visual Investigator before we can proceed with building an aggregation scenario. Within SAS Visual Investigator’s relationship builder window, the relationship should be configured as such:

- “From” entity: Auto Policy
- Cardinality: One-to-Many
- “To” entity: Auto Claim
- Bridge table type: (none)
- Join condition: Policy Id (“Auto Policy” field) = Policy Id (“Auto Claim” field)

Two things to note. Firstly, for SAS Visual Investigator, the order of the pairing matters. A relationship that’s defined as from policy (one) to claims (many) is not equivalent to a relationship that’s defined as from claims (many) to policy (one). The “From” entity in a relationship will later become the actionable entity in our scenario.

Second thing to note is that no additional bridge table is necessary in this relationship definition, as there’s already a claim-to-policy association in the auto_claim table.

Lastly, as a best practice, always reindex your relationships and entities after modification.

The correct actionable entity must be defined. It might be intuitive to assume that since we have loaded the auto claim table, then the actionable entity must be auto claim. This is incorrect. In this case, the actionable entity is actually the auto policies that we are aggregating on.

Configuring the scenario

Once the three prerequisites are met, the building of the scenario can commence. Under the Details section, define Date and time field, Lookback unit, and Group by fields. We want to group by the ID associated with our actionable entity—Policy Id—and use claim incident date as the Date and time field. The lookback unit can be defined as month-to-date or day.

Navigate to the Aggregations tab and configure it as follows to allow us to count the number of claims filed against a policy over a lookback period of six months.

Column to aggregate: claim_id
Metric: count
Lookback (Month-to-date): 6
Offset: 0

Next, navigate to the Rules tab and define the condition as:

If the aggregation is greater than 1, then assign a numerical score.

The scenario configuration is now complete. As a best practice, always test the flow after creating or updating a scenario. The Test Results tab can shed light on the efficacy of your scenario. Use it to fine tune your scenario base on your organization’s unique needs.

Conclusion

The most important takeaways of this post are:

A relationship must be defined between the actionable entity and the data source before SAS Visual Investigator will give you the option to create an aggregation scenario.
In the scenario, the “from” entity of the relationship is the intended actionable entity. (Example: Auto Policies)
In the scenario, the “to” entity of the relationship is intended to be the data source. (Example: Auto Claims)
The relationship must be one-to-many (Example: One policy to many claims) or one-to-one (rare, but possible).

I hope this worked example helped you navigate the finer intricacies of designing and building an aggregation scenario in SAS Visual Investigator.