The following list contains all of the policies for Payments Fraud in Kount 360.
Compare two sets of date variables or custom fields to each other.
Use case:
Use this condition to compare custom fields, like a concert date to the transaction date.
Compare two sets of number variables or custom fields to each other.
Use case:
Use this condition to compare a transaction amount to the customer's average order value.
Text match field against the device browser and version based off of data returned from the Device Collector. Some browsers are either designed for hiding location or other information while other browsers might be indicators of scripted logins.
Examples of browsers that might indicate a level of risk:
-
Electron
-
Goanna
-
YaBrowser (Yandex)
-
Sentry
-
Ice Dragon (Comodo)
Use case:
A company wants high assurance for the location of a user for regulatory concerns. They want to block the usage of any browsers that hide or obfuscate location.
Matching the country in which the device was logged in as captured by DDC (geo-fencing). If the DDC did not run, the device location is determined by the IP address passed with the API call for the event.
Available operators: is in; is not in — allows inclusion or exclusion of one or more countries.
Use case:
A company wants to limit allowing logins to a specific country or region.
Steps to implement this condition:
Ability to create a condition based on whether the device data collection was successful. In some cases, this is unsuccessful when the browser is intentionally blocking collection or when a browser is not being used and the calls are coming from an automation tool, a script, or a bot.
Use cases:
-
A company wants to add friction when there is no device collection to significantly reduce scripted attacks, so they challenge all logins when there is no device collection.
-
A company wants to add friction later in the customer journey (at higher risk activities) when there is no device collection. They create a tag that is sent back with the login API response and then use that as a trigger in their application.
If the order was marked to exclude device data, indicating that device data could not or should not be considered for the order.
Customers can create Policies and Segments based on the length of days that a deviceID has been in our system.
Use case:
A company has identified that logins with devices that are less than a day old are 78 percent more likely to be fraud than other devices. In order to address this, they are setting up a condition that will challenge users logging into existing accounts with new devices.
Steps to implement this condition:
Create a new Policy with the Account Age condition and the Device First Seen condition.
Device Language is a text match that looks for the browser language that the device is using. The device language can be found in Portal under Event Analysis Details or in the Export Report within Dashboard.
Use case:
The customer can create a rule with a tag and apply a No Decision action to know the number of times a particular device language is used. This will help them understand the demand for their product content in other popular languages.
Allows geo-fencing by region.
Use case:
-
A company has regulatory requirements and cannot operate in certain U.S. states.
-
A company has regulatory requirements and can only operate in one Canton in Switzerland.
Boolean evaluation if JavaScript is used by the browser during data collection. This condition evaluates as False for all requests from mobile apps where the Kount Mobile Device Data Collector SDK is integrated. If you have integrated with our mobile SDKs, it is important to use this condition coupled with Mobile SDK = False.
Use cases:
-
A company requires JavaScript for their site to run (even to be able to login). If JavaScript is not detected, it is obvious the user is trying to login outside of their normal path (programmatically).
-
A company has low-tolerance for login discrepancies — they require JavaScript so that they can get device information prior to login.
Mobile Device is a true/false flag indicating if the user is using a mobile device. In some instances, this would be used in conjunction with other rules or would be used for business policy, rather than an identification of risk. Mobile device evaluates if a mobile device, such as a smartphone or tablet, is used.
Text match for identifying the operating system being used. Some operating systems may indicate higher risk of an event being scripted.
Use case:
A company wants to block Windows operating systems that no longer have security patches.
Returns an indicator of input completeness for the address entity.
True if the address is performing freight forwarding or reshipping services.
The match status between either of the input names—person or business—and the queried entity.
Count of days since the email address was first seen in Ekata Identity Network.
The ISO-3166 alpha-2 country code associated with the primary phone number.
The match status between either of the input names—person or business—and the queried entity.
The distance in miles between the shipping and billing addresses.
Score between 0 and 500, where a higher number indicates a higher level of risk.
Comprehensive network score built on behavioral insights, with a higher score indicating a riskier transaction.
Distance in miles between the IP address and the billing address.
Distance in miles between the IP address and the billing phone number registered address.
Distance in miles between the IP address and the shipping address.
Distance in miles between the IP address and the shipping phone number registered address.
Distance in miles between the IP address and the billing address.
Distance in miles between the IP address and the billing phone number registered address.
Distance in miles between the IP address and the shipping address.
Distance in miles between the IP address and the shipping phone number registered address.
The ISO-3166 alpha-2 country code associated with the IP address.
Returns an indicator of input completeness for the address entity.
True if the shipping address is performing freight forwarding or reshipping services.
The match status between either of the input names—person or business—and the queried entity.
Count of days since the shipping email address was first observed in Ekata Identity Network.
True if the person is associated to the resident at the billing address.
The ISO-3166 alpha-2 country code associated with the primary phone number.
The number of orders declined by a fraud agent after a review based on the email address.
The number of payment token authentications declined by a bank for orders based on the email address.
If there is an association between the address in the request payload and the billing address linked to the billing email address.
If there is an association between the name in the request payload and the billing first and last name linked to the billing email address.
The number of days since a billing email address was first recorded in our network across all customers.
Evaluates the billing email address from the request payload against different Melissa Data validation codes for Email Status.
If there is an association between the name in the request payload and the billing first and last name linked to the billing email address.
The number of distinct shipping postal codes associated with the email address.
The number of distinct shipping addresses associated with the email address.
The date that an email address was first recorded in our network across all customers.
Use case:
A company wants to limit the functionality for a customer when they suspect that the email address supplied is not authentic or disposable. They create a policy that identifies when the email is less than 20 days old and flag this challenge. Any challenged attempts must validate their email address within seven days of opening a new account.
The likelihood that the email address is real on a scale of 0 to 100. 100 is more likely to be real than 0.
The proportion of bottom row keyboard characters (Z-M) to consonants in the email username.
The proportion of bottom row keyboard characters (Z-M) to top row keyboard characters (Q-P) in the email username.
The proportion of the first part of the most common billing name in the email username.
The proportion of the last part of the most common billing name in the email username.
The proportion of orders with the most common billing postal code.
The likelihood of an order being placed with the email address again. The score ranges from 0.0 to 1.0, with 1.0 representing a higher possibility.
If there is an association between the address in the request payload and the shipping address linked to the shipping email address.
The number of days since the email address was first recorded in our network across all customers.
Evaluates the shipping email address from the request payload against different Melissa Data validation codes for Email Status.
The IPv4 address of the device. If unavailable, it will be the IP address sent in the request payload.
Evaluation of the IP address passed in with the login request to the IP address collected by the device collector.
When someone logs in via a web browser, a device collection occurs (including capturing the IP address) and a session ID is created. An attacker can take that session ID and use it in a headless browser session to make it look legitimate. Since the IP address differs from when the initial device collection occurred, it can indicate fraud.
IP Mismatch by itself is not a strong enough indicator of fraud to be used to block traffic — it can be used to challenge. It can also be coupled with other conditions but it would still be aggressive as a BLOCK.
Other conditions that could be added to it are as follows:
-
Hosting Facility
-
Proxy
-
IP Anomaly
Which IP address is used, the device collection IP or the IP we pass as userIP during the login decision request?
The IPV4Address is the address found at the time of the device collection, which is used to lookup the IP Org and other IP attributes.
If unable to get the IP Address during device collection, fall back to the userIP sent to Kount by the customer in the Login API (Kount replaces the null value of IPV4address with userIP). Then lookup the IP Org and other IP attributes from the userIP.
Why might the IP Address from the DDC be different from the IP Address passed as userIP (IP Mismatch)?
There are a number of reasons for the device collection IP address to be different from the UserIP address:
Proxy Pierced — potential risk
When initiating device collection, Kount gathers IP information. The IP address is received from the request to download our device collection SDK — this is the earliest Kount can see the end user. However, this request might be coming from a proxy so it may not give us the origin (both the IP address and location) of the machine behind the proxy.
Using a different technique during execution of our device collection, Kount is able to pierce through the proxy. If that is successful, the IP addresses from behind the proxy (the IP address from the initial request to download) is collected.
In this case, the device collection IP address would be the underlying IP, whereas the UserIP would be that of the Proxy.
SessionID re-use for scripts — high risk fraud
Use case:
A script that is unable to run JavaScript is getting sessionIDs from a system that can. On the system that can run JavaScript, the fraudster runs a device collection and gets the sessionID — then uses that sessionID within the script for the attack (making it look like they have legitimate device collection).
The script may be running from a hosting solution or somewhere different from where the device collection was run.
Mobile — low risk
The IP address gathered from device collection is a point-in-time. Our device collection lessens an incoming request within a certain time period (15 minutes) if there is already a collection for that session ID. If a Login request is made with a sessionID where the device collection was made within the last 10 days, Kount uses the information from the device collection associated with the sessionID.
Depending on how the customer’s site works with sessions and device collections, there is potential for a mismatch if the user has moved.
Use case:
A user opens a site, which initiates device collection, to check the balance on a gift card. The device collection gets an IP address and Kount stores that information with the sessionID for this session. The user does not put in the gift card information to check the balance, but leaves the page open in the browser.
Later that day, the user remembers that she wanted to check the balance on the gift card. She enters the info and clicks submit. Because she left the browser window open, she is using the same sessionID and no new device collection occurs (since that happens on page load).
When the customer sends the Login request, the IP address from the current time is passed for the user. Since she is on a mobile device and connected to a different mobile tower, she is leaving a different exit node, which provides a different IP address.
Evaluation of the device during login against a range of IPs — the range can only be within the final octet. For example: nnn.nnn.nnn.035 through nnn.nnn.nnn.200. The range can be a maximum of 255 values (001-255).
Use case:
A company wants to remove friction for their call center. They create a Segment for the IP range that the call center uses and do not add Policies to it to ensure their call center employees are not blocked or challenged.
Evaluation of the IP address of the device during login.
Use cases:
-
A fraud agent notices a single IP address is going nuts on the failed attempts. She tries to contact IT, but no one is available. She sets a condition to block the IP address until they can come help.
-
A company wants to reduce friction for its call center when logging into the portal — so it sets a Segment based on the IP addresses from the call center.
True or false if a proxy has been identified during the login process.
Use case:
A company has a medium tolerance for risk. They block traffic from known proxy services when there is no device collection.
A true/false flag indicating the use of a TOR network. IF the TOR network is being used, the location of the user has been highly anonymized, and there is no reliable way to use attributes to identify device authenticity.
Use case:
A company has a medium tolerance for risk. They block all traffic from TOR.
Other parts of the street address of the billing address, such as an apartment number.
Checks the billing address against a variety of Melissa Data result codes to verify that the address is valid.
Evaluates the email address against different Melissa Data validation codes for the email status.
Checks a billing phone number against a variety of Melissa Data result codes to verify that the number is valid.
If the billing and shipping addresses supplied by the customer match.
Data sent in the request to the POST Orders endpoint. This data designates traffic or transactions associated with a specific channel, either store, website, or fulfillment center.
The number of a specific type of chargeback, such as Incorrect Currency (Visa), for a customer's card from the merchant's data.
The number of a specific type of fraud file, such as TC40 (Visa), for a customer's card from the merchant's data.
The number of a specific type of chargeback, such as Incorrect Currency (Visa), for a customer's card from the merchant's data.
The number of a specific type of fraud file, such as TC40 (Visa), for a customer's card from the merchant's data.
-
TC40 (VISATM)
-
SAFE (MastercardTM)
-
Other FIle
-
No File
Other parts of the street address of the shipping address, such as an apartment number.
Checks the shipping address against a variety of Melissa Data result codes to verify that the address is valid.
Evaluates the email address against different Melissa Data validation codes for the email status.
Evaluates the customer name against different Melissa Data validation codes for the shipping name status.
Checks the shipping phone number against a variety of Melissa Data result codes to verify that the number is valid.
The number of devices associated with this persona in the 14 days before the order.
The number of email addresses associated with this persona in the 14 days before the order.
The number of payment methods associated with this persona in the 14 days before the order.
The velocity of the floating 6-hour period in the 14 days before the event, when the most approved and declined orders occurred.
The riskiest location identified in the Persona cluster. This could include billing, shipping, or device location. The score is aggregated from customer-provided data.
The sum of all approved orders authorized by the issuing bank in the 14 days before the order.