Delaying or delegating event processing: alerts and alert management
Events that cannot be handled immediately can be placed in an alert category. Alert categories and alerts are used to filter rule Rules are used to define sets of criteria to verify if an event (transaction and non-monetary event) matches any fraudulent behavior. If an event matches a previously defined rule, an alert can be raised. matches; typically, high, medium, and low risk alerts with correlating rules are created. With this you are able to target the highest risk rules at highest priority at the alert level. The Alert Management navigation pane displays all available alert categories and alerts.
If a hierarchy record raises an alert, the alert and the corresponding record When a pending alert becomes available for processing, a unique alert record is created that can be tracked throughout its life cycle. Alert records are never reopened; once closed, they remain closed. In the event that a case must be reopened, a new alert record is created. must be checked to verify which rules have been matched and caused the alert. The next step is then to define which action must be taken. In the Alert Management tab Risk Analytics Presentation Service A highly dynamic web interface that provides webpages for the user to intuitively interact with Risk Analytics. It is a Microsoft .NET 4.7.2 ASP.NET application hosted inside Microsoft Internet Information Services (IIS). facilitates the definition and further handling of alerts. Managing the alerts centrally ensures control over the priority in which alert records will be placed.
The same alert for an event matching a given rule or set of rules can only be raised once by the same user in the same campaign Decision campaigns group elements in a hierarchical structure to filter events and ensure that the raised alerts can be processed adequately. Campaigns target specific record types such as for instance approved transactions only. A campaign is the top filtering level.! If the same event matches the same or other rules in the same campaign, no further alert is raised; this and all further events matching this rule can be reviewed in the SUPERVISE & INVESTIGATE menu.
Alerts can also be managed via a filtering system. Filter levels include:
- Alert campaigns. Used to isolate different fraud-management disciplines; e.g. transaction fraud prevention and application fraud prevention. This enables you to generate multiple pending alerts for the same account where this is required.
- Alert divisions. Prioritized grouping of alert categories.
- Alert categories. Containers with the pending alert(s).
By defining an alert campaign consisting of an alert division and category, you will be able to set an action on a rule. With this, decision matches are linked to this alert.
-
Navigate to DESIGN RULES & ACTIONS > Alert Management.
-
In the navigation pane, click Add Campaign to add an alert campaign.
-
Enter a name and a description for the alert, and click Save.
The alert campaign you have just created is displayed in the main window.
-
Click Add Alert Division to add an alert division.
-
Enter the division name.
-
Enter the priority for the division; possible values range from 1 as the highest to 9 as the lowest priority.
-
Add a description of the division.
-
Select the alert type from the list.
-
Click Save.
-
Click Add Alert to add an alert category.
-
Enter an alert category name and description.
We recommend entering a meaningful name to describe which rules will be contained here, and an explanation of the rule matches. This ensures that the pending alert is actually linked to this alert for the description.
-
Enter the number of sticky days for this alert category.
-
Enter the priority for the alert category; possible values range from 1 as the highest to 9 as the lowest priority.
-
Enter the number of minutes for the target lock.
-
Enter the number of minutes for the target complete.
You can edit the alert category at any time via the Edit button that is displayed in the dashboard of any alert.
If you want the same relationship hierarchy Data inside Risk Analytics is stored in the relationship hierarchy - the data is organized in a single-customer view. The relationship hierarchy consists of several layers, or items, and is rendered and managed in the form of pending alerts. (applies to the three top hierarchy levels: relationship, application, account) to raise two pending alerts on the same campaign, the alert categories have to be created in two different alert campaigns.