- 22 Oct 2024
- 4 Minutes to read
- DarkLight
Rules Actions and Response Status
- Updated on 22 Oct 2024
- 4 Minutes to read
- DarkLight
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. |
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. :
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..
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—launch an external procedure.
Alert Category Placement—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. For more information about setting a response and/or a status for a rule, see Setting the response/status.