Rules, actions, and response/status

In Risk Analytics, rules are used to define sets of criteria to verify if an event matches any fraudulent behavior. Rules are basic elements that contain basic criteria, historical criteria (based on customers historical data), or match criteria (based on the match key of historical data that include the history of a device, history of a beneficiary, or a location across all customers). Rule types in Risk Analytics provides an overview of rule types and the target monitored with the relevant rule type.

Rule types in Risk Analytics

Rule type	Rule target
Boolean rule	Evaluates record by record with basic logic, using definable criteria. Boolean rule workflow
History rule	The purpose of history criteria is to monitor an event over a defined period. History criteria analyze historical data with basic logic and additionally apply volume and/or velocity controls; historical data are filtered either by the relationship, application, or the account of a relationship. : Velocity rule. Evaluates, if the number of records exceeds a defined number over a given period. Volume rule. Evaluates, if the sum of a field of those records that match history criteria exceeds a defined value over a given period, e.g. the sum of a transaction amount. The Difference option of a history rule allows applying the velocity to records that have distinct values from the record with the selected field of the current event. The Same option of a history rule allows applying the velocity to records that have the same value as the record of the selected field of the current event.
Match rule	The purpose of Match Criteria is to monitor an event over a defined period and over all relationships, ie. customers. This means that Match Criteria, unlike the history rules, does not look back historically over the events of a single customer (via the accounts or the customer’s PAN) but over events of several customers. With Match Criteria, you can for example look at events carried out with the same beneficiary by different customers Match Criteria analyze historical data with basic logic and additionally apply volume and/or velocity; historical data are filtered by the defined match keys.. Velocity rule. Evaluates, if the number of records matching match criteria exceeds a defined number over a given period. Volume rule. Evaluates, if the sum of a field of records matching match criteria exceeds a defined value over a given period, e.g. the sum of a transaction amount. The Difference option of a history rule allows applying the velocity to records that have distinct values from the record with the selected field of the current event. The Same option of a history rule allows applying the velocity to records that have the same value as the record of the selected field of the current event.
Memory rule	Combines two rules to link two independent events which consequently form a single rule. With this, complex sequences can be defined by allowing the system to remember a rule’s classification and then making reference to this in a subsequent rule.

By defining a corresponding rule, you can for instance analyze and filter events for any transactions that have been carried out in Great Britain:

Basic rule for an event to match if any transaction is carried out in Great Britain

The criteria definition of this rule in Risk Analytics Presentation Service is:

• From the Criteria list menu, select IS and IP_COUNTRY_ALPHA_COD and =; enter GB in the input field for that list menu.

With this criteria definition, any event taking place in Great Britain will match this rule, and a matched record will be generated. This record is then available for further investigation and/or supervision in Risk Analytics Presentation Service.

For more information about creating rules and examples of typical rule creation workflows, see The Create Rule and Action Wizard.

If an event matches any of the defined rules or a set of rules, you can define which action is to be taken for the transaction that has matched the rule. You can also define Response / Status actions to amend the .xml of the transaction before a response is sent. This means you could for example decline a transaction, by changing the response code to decline, or take a similar action before sending the response. For more information about creating actions for a rule, see Creating actions.

Risk Analytics Presentation Service offers several types of actions that can be defined. The following actions are available:

• Set up and/or modify a response code
• Launch Workflow An action in Risk Analytics Presentation Service that serves to start and/or customize a workflow to connect the selected item to a remote process or workflow.—launch an external procedure.
• Alert Category Placement An action in Risk Analytics Presentation Service that serves to raise an alert for a matched record and make it available in the SUPERVISE & INVESTIGATE menu for further review.—create an alert for events that have matched one or several rules.

You can also define a required Response / Status. The defined Response / Status enables you to amend the event’s .xml file before a response is sent. This means you could decline a transaction by changing the response code to Decline, or change the action for the fraud disposition. The RESPONSE_CODE = DECLINE option is available at rule level for applications in the 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.. For more information about setting a response and/or a status for a rule, see Setting the response/status.