Rules and Risk Processing

CA RiskMinder Windows Installation Guide › Understanding the Basics › Introduction to RiskMinder › Rules and Risk Processing

Rules and Risk Processing

After the required data is collected, it is forwarded to Rules Engine (a module of RiskMinder Server). The Rules Engine is a set of configured rules that evaluate this information, which is based on incoming information and historical data, if available.

A rule, in turn, is a condition or a set of conditions that must be true for a rule to be invoked. By default, each rule is assigned a priority and is evaluated in the specific order of its priority level. However based on your business requirements, you can change this priority of rule scoring.

The out-of-the-box rules that are provided by RiskMinder are explained in the following table.

Rule Name	Description
Exception User Check	An organization may choose to exclude a user from risk evaluation during a certain time interval. For example if a user travels to a country that is configured as negative in RiskMinder, then for the specified interval their status can be changed to an exception user. RiskMinder returns a low risk score for transactions originating from exception users and the advice is typically Allow.
Untrusted IP Check	This list constitutes the IP addresses that originate from anonymizer proxies or have been the origin of known fraudulent or malicious transactions in the past. Transactions originating from configured negative IP addresses receive a high score and the advice is Deny.
Negative Country Check	This list comprises the countries that have been known to be origins of significant number of frauds in the past. RiskMinder derives the country information based on the input IP address, and then uses this data to return a high risk score for online transactions originating from these "negative" countries. Transactions originating from configured negative countries receive a high score and the advice is Deny.
Trusted IP/Aggregator Check	Transactions originating from IP addresses "trusted" to the organization receive a low score, by default, and the advice is Allow. Many enterprises use the services of account and data aggregation service providers to expand their online reach. The originating IP addresses when users log in from a protected portal versus when they come in through such aggregators are different. Transactions originating from aggregators "trusted" to the organization receive a low score, by default, and the advice is Allow.
Unknown User	An unknown user is not registered in the RiskMinder database. If the user is unknown to RiskMinder, then by default an Alert is returned. A Customer Support Representative (CSR) can then choose to further authenticate the user based on the advice.
Unknown DeviceID	The Device ID is a device identifier string that RiskMinder generates and stores on the end user’s device to identify and track the device that the end user uses for logging in to your online application to perform transactions. RiskMinder returns a low risk score for transactions originating from known devices and the advice is typically Allow.
User Not Associated with DeviceID	Transactions originating from a known device that is associated with a user, and whose DeviceDNA matches, receive a low score, and the advice is Allow. Transactions originating from a known device that is not associated with a known user receive a medium score, and the advice is IncreaseAuth. Note: See the sections "User-Device Associations", "Machine FingerPrint (MFP)", and "DeviceDNA" for more information about these topics.
Device MFP Not Match	Transactions originating from a known device whose DeviceDNA does not match receive a medium score, and the advice is IncreaseAuth. Transactions originating from an unknown device that is not associated with a known user receive a high score, and the advice is Deny. Note: See the sections "User-Device Associations", "Machine FingerPrint (MFP)", and "DeviceDNA" for more information about these topics.
User Velocity Check	Frequent use of the same user ID could be an indication of risky behavior. For example, a fraudster might use the same user ID and password from different devices to watch a specific activity in a targeted account. Too many transactions originating from the same user within a short (configurable) interval receive a high score and the advice is Deny.
Device Velocity Check	Frequent use of the same device could also be an indication of risky behavior. For example, a fraudster might use the same device to test multiple combinations of user IDs and passwords. Administrators can now configure RiskMinder to track this behavior, as well. Too many transactions originating from the same user device within a short (configurable) interval receive a high score and the advice is Deny.
Zone Hopping Check	If a user logs in from two long-distance locations within a short time span by using the same user ID, this might be a strong indication of fraudulent activity. In addition, a User ID can also be shared, in which case, RiskMinder understands that the two people sharing the same User ID can be in geographically different locations and responds with an appropriate response. Transactions originating from the same user from locations that are far apart from each other within a short (configurable) interval receive a high score and the advice is Deny.

The Rules Engine executes these rules in the order of their precedence. The evaluation result is then forwarded to another module of the RiskMinder Server, which is known as the Scoring Engine. Between Rules Engine and Scoring Engine, the rules are run in the following two phases:

Execution Phase
RiskMinder Server does a first parse of all the rules in the active ruleset. In this phase, the Server:
1. Executes all the rules in the list in the order of execution priority.
  This execution priority is internal, and is defined by the Server.
2. Generates an individual risk score and advice for each rule it executes.
Scoring Phase
RiskMinder Server now does the second parse of the rules. In this phase, the Server:
1. Uses the result for each rule in the first parse, and parses the rules in the ruleset based on the scoring priority.
  The Global Administrator (GA) configures the scoring priority by using the Administration Console.
2. Stops the scoring at first matched rule.
3. Returns the score and advice of the rule that matched as final.

Note: Depending on when the first rule matched, the second parse may not be run completely.