Understanding the Data RA Uses
Risk Analytics bases the result of a risk analysis by comparing the following incoming information, if available, with the historical data for the user:
cara
Risk Analytics bases the result of a risk analysis by comparing the following incoming information, if available, with the historical data for the user:
- User Data
- Transaction Data
- Case Management Data
- Model Data
- Currency Data
The following figure illustrates how Risk Analytics uses this data. The following subsections provide a quick overview of each of the data categories.

How Is Geolocation Information Derived from IP Address Used
RA uses the IP address of the end user's device to derive geo-location information, such as locale, ISP, time zone, and related geographical information.
To obtain this information, RA works with Neustar®, who specialize in providing detailed geographic information for each IP address by mapping it to a region.
This information is especially useful in pre-login risk assessments, where RA does not have any other transaction data yet. For example, if RA decides that the IP address is from a designated negative country (such as Nigeria), then it generates DENY. In this case, your application can choose to not even display the login page.
Note:
SeeWhere Can this Data be Used
You can use this location information in the following rules:
- Exception User Check
- Trusted IP/Aggregator Check
- Untrusted IP Types List
- Negative IP Address List
- Negative Country List
- Zone Hopping
- Other custom rules that you create using IP address, city, state, country, ISP, or time zone as rule variables
How Is Geolocation Data Derived from Address Used
For non-Internet-based, card-present channels, such as ATM and POS, RA derives the geolocation (latitude/longitude) information in two ways:
- If theZIPCODE(orPINCODE) of the Card Acceptor (ATM Terminal or Merchant) is available, then the same is used to derive the geolocation mapping data.
- If theZIPCODE(orPINCODE) data isnotavailable, then the CITY or STATE or COUNTRY information available for the Card Acceptor (ATM Terminal or Merchant) is used to derive the geolocation mapping data.
Card Acceptor’s ZIPCODE (or PINCODE) to determine the following geolocation mapping data:
- City
- State
- Country
- Latitude
- Longitude
Note:
See Understanding Data Elements for detailed information on all Geolocation Elements that you can use to create custom rules.Where Can this Data be Used
You can use this geolocation information in the following rules:
- Zone Hopping
- Negative Country
- Other custom rules that you create using city, state, or country as rule variables
How Is Geolocation Data Derived from Anonymizers Used
IP addresses can also be classified with an anonymizer status. You can control the types of anonymizer IPs that you include in the rule. The different categories of negative IP types are:
- Negative
- Active
- Suspect
- Private
- Inactive
- Unknown
You must either set the rule to the defaults listed or you must clear Suspect IPs. While the use of an anonymizer does not necessarily indicate intent to commit a crime, it is highly suspicious because the user is masking their location. For example, users may be participating in marginal activities such as accessing gaming from a country where it is not allowed or accessing video or music content from a region that is not licensed. The hit rate for this rule is highly variable by customer because it is influenced by the portfolio of end users. However, the approximate review rate based on Anonymizers is 0.1% (one in 1000 transactions). False positive rates tend to vary greatly from as low as 20:1 for US and European users to as high as 100:1 for less developed regions.
Note:
See Understanding Data Elements for detailed information on all Geolocation Elements that you can use to create custom rules.Where Can this Data be Used
You can use this geolocation information in the following rules:
- Zone Hopping
- Negative Country
- Other custom rules that you create using city, state, or country as rule variables
How Is Zone Hopping Information Used
The location latitude and longitude are the most important information used in the
Zone Hopping Check
rule. This rule verifies the time and speed required for physically travelling between the points of origin of two successive transactions using the IP addresses that were used.If two successive transactions are originating at at a speed beyond what is reasonably possible within a short time span, then you must conclude that either two different people were accessing the same account from different locations or the user did something, either intentionally or inadvertently, to mask their true location. As a result, you can use this as a Deny rule.
It is highly recommended that you start by setting the values of the Zone Hopping Check rule to the default values provided. Based on the performance of this rule over time, you can tune the settings of this rule to make them more precise.
In its default settings, you should expect the rule to fire about 0.02% of the time. The false-positive rate for this rule is good at under 10:1.
Note:
See Understanding Data Elements for detailed information on all Geolocation Elements that you can use to create custom rules.Where Can this Data be Used
You can use this geolocation information in the following rules:
- Zone Hopping
- Other custom rules that you create using city, state, or country as rule variables
How Is Negative IP Address List Used
The Negative IP Check Rule performs two functions within a single rule:
- The rule checks the IP addresses of end users against the list of known anonymizer proxies.
- The rule consults the Negative IP address list that you define to verify whether the IP is in one of the ranges defined in your table.
You can use the Manage List Data and Category Mappings page in Administration Console to add IP Addresses to the Negative IP address list. The rule performance for blacklisted IP addresses depends on how you manage your list. Typically, you add IPs to the list when you see fraudulent or risky access that you want to stop and you remove IPs from the list when a legitimate user requests for the same.
Note:
See Understanding Data Elements for detailed information on all Geolocation Elements that you can use to create custom rules.Where Can this Data be Used
You can use this geolocation information in the following rules:
- Negative Country
- Other custom rules that you create using city, state, or country as rule variables
How Is Device Identification Data Used
The following subsections briefly walk you through the device identification and analytics technique used by Risk Analytics:
- Device ID
- Machine FingerPrint (MFP)
- DeviceDNA
RA matches this incoming device data against the stored information to fine tune the score and advice.
Note:
See Understanding Data Elements for detailed information on all Device Elements that you can use to create custom rules.Where Can this Data be Used
You can use this device-related information in the following rules:
- DeviceID Known
- Device MFP Match
- Device Velocity Check
- Other custom rules that you create using Device Elements
Device ID
The
Device ID
is a server-generated identifier that RA generates and sets on the end user’s system to identify and track the device when the end user logs in to your online application and performs transactions. The information is stored in the RA database in an encrypted format.The Device ID is stored as a Browser cookie, which is an HTTP identifier’s extension and storage location depends on the browser used by the end user.
Note:
Device ID is not available to Risk Analytics when it evaluates a device for the first time. This data is used in subsequent evaluations.When a user is evaluated by RA for the first time, it generates this cookie and sets it on the user’s system. Every subsequent time the user is assessed, RA verifies if the Device ID on the user’s system matches the Device ID stored in the RA database. If the two Device IDs match, the incoming information is considered "safe".
Machine FingerPrint (MFP)
Machine FingerPrint
(also referred to as Device fingerprinting or PC fingerprinting in industry terms) represents the browser information and device identification attributes (such as operating system, installed software applications, screen display settings, multimedia components, and other attributes) that are gathered from the end user’s system and are analyzed to generate a risk profile of a device in real time. Some of the attributes that are collected from the end user’s device include:- Browser information (such as name, UserAgent, major version, minor version, JavaScript version, HTTP headers)
- Operating system name and version
- Screen settings (such as height, width, color depth)
- System information (such as time zone, language, system locale)
For every transaction performed by the end user, Risk Analytics matches the corresponding MFP stored in its database with the incoming information. If this match percentage (%) is equal to or more than the value specified for the Device-MFP Match rule, then it is considered "safe".
DeviceDNA
DeviceDNA
is a device identification and analytics technique that uses both Machine FingerPrint (MFP) and Device ID for more accurate information analyses. For accuracy, more information is collected than in case of MFP. For example:- Additional system information (such as platform, CPU, MEP, system fonts, camera, and speaker information)
- Additional browser information (such as vendor, VendorSubID, BuildID)
- Additional screen settings (such as buffer depth, pixel depth, DeviceXDPI, DeviceYDPI)
- Plug-in information (such as QuickTime, Flash, Microsoft Windows Media Player, ShockWave, Internet Explorer plug-ins)
- Network information (such as connection type)
How Is Device User Association Data Used
RA uniquely identifies a user as a valid user by automatically associating (or binding) a user to the device that they use to access your application. This is referred to as a
user-device association
(or device binding
) in RA terminology. Users who are not bound are more likely to receive the Increase Authentication advice.RA also allows users to be bound to more than one device. For example, a user can use a work and a home computer to access your application. Similarly, you can bind a single device to more than one user. For example, members of a family can use one computer to access your application.
Note:
See Understanding Data Elements for detailed information on all Device Elements that you can use to create custom rules.Where Can this Data be Used
You can use this device-related information in the following rules:
- User Associated with DeviceID
- Other custom rules that you create using Device Elements
How Is User Information Used
Typically, a user's login ID (USERNAME) identifies a user uniquely in the system. RA uses this information as one of the attributes to identify the risk associated with an incoming transaction. If a user exists in the Risk Analytics database, the user is considered "known", and therefore, less risky. Also, RA can match the incoming user against the stored information to further fine tune the score and advice.
Where Can This Data Be Used
You can use this user-related information in the following rules:
- Exception User Check
- User Known
- User Associated with DeviceID
- User Velocity Check
How Is Transaction Information Used
Using a custom rule, RA can also accept contextual or transaction information for analyzing the risk associated with a transaction. This information includes:
- Transaction amount
- Transaction type
- Transaction date
See Understanding Data Elements for detailed information on all Transaction Elements that you can use to create custom rules.
Where Can this Data be Used
You can use this transaction-related information in the following rules:
- Custom rules that you create using transaction data elemets
How Is Case Management Information Used
The
Case Management
feature of RA provides administrators and fraud analysts a single unified view of the data related to suspect transactions (or cases). This helps in the efficient analysis of collected data and take faster, better-informed decisions towards determining fraud patterns.This feature also allows you to constantly track the status and progress of cases and maintain complete case histories with instant access to all related information. As a result, Case Management is an efficient tool to analyze data and identify new patterns of fraud from historical data. These patterns, in turn, can be used to configure new rules to reduce fraud.
Where Can this Data be Used
Case Management data serves very useful in:
- Locating suspicious transactions and patterns.
- Testing effectiveness of deployed rules (with the help ofRule Effectiveness Report).
- Determining false positives (with the help ofFalse Positives Report). If the false positives ratio is high, then also rules need further fine-tuning.
How Is Model Information Used
When you create and deploy an RA Model, it generates a score, typically in a range from 0 through 100. This score is available as a part of the system parameter called
PREDICTIVE_SCORE
(for DSP) and MODEL_SCORE
(for GDP).When you configure this parameter alone or in conjunction with other data elements as a part of a custom rule and enable the rule, RA can further fine tune a risk advice.
Note:
See Understanding Data Elements for detailed information on all Model Elements that you can use to create custom rules.Where Can this Data be Used
You can use this Model-related information in the following rules:
- Custom rules that you create using Model data elemet
How Is Currency Conversion Used
When the transaction currency and the base currency of the organization to which the user belongs are different, then RA automatically converts the transaction amount to the base currency of the organization.
Some rule operators in specific channels allow you to specify the threshold amount in multiple currencies, in addition to specifying it in the base currency of the organization. When such a rule is executed, the transaction currency is compared with the currencies in which the threshold amount has been specified:
- If a match is found, then the transaction amount is directly compared with the threshold amount in that currency. In this case, no currency conversion is required.
- However, if a match is not found, then the transaction amount is first converted to the base currency and then compared with the threshold set in the base currency.
Setting one of the threshold amounts in base currency is mandatory.
The following examples illustrate how this feature works:
Example 1
You have configured a rule with threshold amounts in USD, JPY, and AUD, while the organization base currency is USD. The following scenarios explain how currency conversion takes place during various types of transactions:
- Scenario 1: A transaction is being conducted in USD. Because the transaction currency is the same as the organization's base currency, the specified threshold is used without any need for currency conversion.
- Scenario 2: A transaction is being conducted in JPY. Because JPY is one of the currencies in which the threshold amount has been specified, the transaction amount is directly compared with the threshold amount in JPY. No currency conversion is required in this scenario.
- Scenario 3: A transaction is being conducted in EUR. Because EUR isnotone of the currencies in which the threshold amount has been specified, the transaction currency is first converted from EUR to USD. The threshold value specified in USD is used for the comparison.
Example 2
You have configured a rule with threshold amounts in GBP, JPY, and AUD, while the organization base currency is GBP. The following scenarios explain how currency conversion takes place during various types of transactions:
- Scenario 1: A transaction is being conducted in GBP. Because the transaction currency is the same as the organization's base currency, the specified threshold is used without any need for currency conversion.
- Scenario 2: A transaction is being conducted in JPY. Because JPY is one of the currencies in which the threshold amount has been specified, the transaction amount is directly compared with the threshold amount in JPY. No currency conversion is required in this scenario.
- Scenario 3: A transaction is being conducted in EUR. Because EUR isnotone of the currencies in which the threshold amount has been specified, the transaction currency is first converted from EUR to USD and then from USD to GBP. The threshold value specified in GBP is used for the comparison.