Kount 360 Conditions

Account Creation Score uses our identity network and machine learning to assess the risk of an account creation. The score ranges from 0.1 (unsafe) to 99.9 (safe) and can be seen in New Account Opening reports.

The score analyzes:

This condition is evaluated as less than, greater than, or equal to score criteria entered by you during policy creation.

Use cases:

To create a new segment or policy using this condition, go to Manage Segments or Manage Policies.

Omniscore is the order safety rating that ranges from 0.1 (unsafe) to 99.9 (safe).

The condition is evaluated relative to the number you enter, such as 35.

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.

Compare two sets of string variables to each other.

Use case:

Use this condition to compare a billing city to a shipping city.

This condition allows you to instantly match high-risk network data against order locations.

This condition allows the use of any given data point to be block-listed, allow-listed, or used to weight a decision. It allows the customer to check whether the value in a Custom Field is in a specified list.

Use case 

A customer finds that gift certificate fraud is more highly correlated with the person a gift certificate was bought for rather than who bought the gift certificate. The merchant sends the recipient’s email address in a UDF. They then can create a blacklist of gift certificate recipient emails, which significantly reduces their gift certificate fraud.

Use one of the following custom fields in the event a pre-made policy does not fit your needs.

Checks whether the values in the selected NUMBER or DATE custom fields are present in a selected list.

Use case

A company sends a custom field set with the identifier of their nearest store. The company keeps a list that puts orders in review for certain high-risk locations. An order is processed, and the condition checks if the location is in the high-risk location list. If a high-risk location ID is present, the order is automatically placed in Review.

Checks whether the values in the selected STRING custom fields are present in a selected list.

Use case

An order contains a high number of 20%-off coupon codes. This might indicate a promotional abuse.

Coupon codes provided in a custom field can be checked against a list of risky coupon codes.

Evaluates if IsAppleRelay is enabled on the device.

Assigned Trust State is dependent on integration with the trusted device API. This condition evaluates the device trust state for the user logging in.

The condition is evaluated as is or is not one or more of the following:

Use case:

A company wants to reduce friction for users when they sign in with a trusted device by applying a limited policy set.

Once the segment is created, users that login with a trusted device are subject to any policies assigned to the segment. If no policies are added, then all users that log in with a trusted device are accepted. If Policies are assigned to the segment, they're evaluated for an Accept/Block/Challenge response.

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:

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.

Will trigger when the Device Data Collector runs successfully.

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:

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:

Evaluates the device risk when device data collection is successful. It also evaluates the network risk based on the user IP sent in the request payload.

Set Device Risk for is in or is not in for the following risk levels:

Friendly Name is a text match that looks for the friendly name of the device if the device has a trust relationship with the user. The logic for this functionality is as follows:

This condition provides the most value when used with Trusted Device Functionality. It is useful when the Friendly Name is set using a codified methodology — especially useful when a customer is using a trusted device for different use cases.

For example, the friendly name could be set to identify user-preferences. If one use case for Trusted Device is for Login (the user had to select the checkbox to remember this device at login) and the other use case was for account change (allow this device to make changes to this account), the friendly name could be set to login, account-change, or login-and-account-change depending on the user’s preference. Then policies could be set for the specific use-cases while keeping the user’s preferences in mind.

Use case:

The customer has a single clientID but manages multiple sites that share userIDs. They want to manage trust relationships on a per-site basis, but they also want to know when the device is trusted for a user on the other site. By adding a site identifier into the Friendly Name, conditions can be created to tag the Login API response with all of the sites that the user has trusted relationships for. Additionally, the customer can identify when a user has a banned trust relationship on one or more of their sites.

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 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:

The local date and time of the user based on the time zone settings of the device.

Location Accuracy defines the accuracy of the device location using the following criteria:

Use case:

When proxy is detected and we pierce the proxy, the location is accurate. When proxy is detected but not pierced, the location information should not be considered as valid. Exposing the device accuracy helps analysts know when to trust the device location. If the device location is not accurate, then the transaction might be suspect.

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.

Mobile SDK is a true/false flag that indicates if the end-user is using a mobile app that has integrated our SDK. This can be used in conjunction with other rules or used for business policy — rather than an identification of risk.

Use case:

A company requires JavaScript for their website to run, maybe even to be able to log in. But they also have a mobile application and use the Mobile SDK for device collection. They add Mobile SDK = False to their JavaScript rule to make sure they are not blocking legitimate traffic from customers that use the mobile app.

The type of mobile device, such as an iPhone or Android phone.

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.

The time zone settings of the device in Greenwich Mean Time (GMT). For example:

Returns an indicator of input completeness for the address entity.

True if the address is performing freight forwarding or reshipping services.

True if the address is a business address.

True if the billing address is valid.

The match status between either of the input names—person or business—and the queried entity.

Indicates the delivery point for the address.

True if there is a warning associated with the billing address.

The number of days since the email domain was created.

Count of days since the email address was first seen in Ekata Identity Network.

True if the billing email is potentially autogenerated.

True if the billing email domain is disposable.

True if the billing email is valid.

The match status between the input name and the queried entity.

The company that provides voice and/or data services for the phone number.

The ISO-3166 alpha-2 country code associated with the primary phone number.

True if the phone number is registered to a business.

True if the phone number is associated with a prepaid account.

True if the phone number is valid.

The line type of the phone number. For example, Landline or Toll-free.

Returns a match status between the input address and the queried entity.

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.

The name of the city in the structured address.

The two-letter continent code of the 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 name of the city in the structured address.

The two-letter continent code of the address.

The ISO-3166 alpha-2 country code associated with the IP address.

The name of the country in the structured address.

The postal code of the structured address.

True if the IP Address is valid.

True if the IP address is considered risky.

The match status between the input name and the queried entity.

The match status between the input name and the queried entity.

True if there is a warning 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.

True if the shipping address is a business address.

True if the shipping address is valid.

The match status between either of the input names—person or business—and the queried entity.

Indicates the delivery point for the shipping address.

Tue if there is a warning associated with the shipping address.

The number of days since the email domain was created.

Count of days since the shipping email address was first observed in Ekata Identity Network.

True if the shipping email is potentially autogenerated.

True if the shipping email domain is disposable.

True if the shipping email address is valid.

The match status between the input name and the queried entity.

True if the person is associated to the resident at the billing address.

The company that provides voice and/or data services for the phone number.

The ISO-3166 alpha-2 country code associated with the primary phone number.

True if the phone number is registered to a business.

True if the phone number is associated with a prepaid account.

True if the shipping phone number is valid.

The line type of the shipping phone number.

Returns a match status between the input address and the queried entity.

The match status between either of the input names—person or business—and the queried entity.

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.

The average number of line items in the cart associated with 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.

Trustworthiness of the billing email address.

The number of chargebacks for orders associated with the 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 distinct shipping postal codes associated with the email address.

The number of distinct billing states associated with the email address.

The number of distinct billing names associated with the email address.

The number of distinct bank identification numbers associated with the email address.

The number of different calendar days that the billing email address was used to place an order.

Use case

A fraudster gains unauthorized access to a legitimate customer's account, known as an Account Takeover. This access could be obtained through a data breach, phishing, or malware. The fraudster's goal is to place as many high-value orders as possible, using the stolen stored payment information or placing numerous test orders before the customer notices the suspicious activity or the bank flags the card.

You can use this policy to detect a rapid, concentrated burst of activity from a single compromised account/email address that is characteristic of a fraudster testing card validity or maximizing unauthorized purchases before the account is locked.

The number of distinct days of the week associated with the email address.

The number of distinct IP addresses associated with the email address.

The number of distinct merchant IDs associated with the email address.

The number of distinct months associated with the email address.

The number of distinct payment tokens associated with the email address.

The number of distinct shipping addresses associated with the email address.

The number of distinct shipping names associated with the email address.

The number of distinct years 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 number of characters of the email address with the domain name.

The number of characters of the email address without the domain name.

Identifies if the email address and the physical address supplied by the customer have been associated in our network.

Use case:

A company wants assurance that the email address is associated with the physical address before sending the customer marketing material in the mail.

They create a no decision policy to flag when an association exists between the email address and the mailing address provided by the end user at signup. When there is an association, we will send a tag in the NAO response and the company will know it can send physical mail to the customer.

Identifies if the email address and the name supplied by the customer have been associated in our network.

Use case:

A company wants a high level of assurance that the email address being used has been associated with the person signing up, and that they have control of the email address. If it is not, they will require additional customer information before the account is opened.

When the end user enters the email address and name, the company sends a New Account Opening request to us. If there is no association between the email address and the name provided by the new user, a challenge is issued and the company asks for financial information that it can validate for the user.

Evaluates the email address from the NAO request payload against different Melissa Data validation codes for Email Status. Refer to Melissa Data Validation Codes for a list of all the validation codes.

Use cases:

A machine learning model that looks at the general trustworthiness of an email address.

Use case:

A company wants to flag when an email has a very low trustworthiness score to deny bonus loyalty points to the new user until they have 15 activity events within their portal.

They create a new decision policy that flags NAO events when the Email Trustworthiness is Low or Very Low. When they receive the tagged response from us, their system flags the account and requires the added activity.

Highest dollar amount of all orders recorded from the email address.

The mean Omniscore associated with the email address.

The minimum Omniscore associated with the email address.

The number of orders with the most common billing address.

The number of orders with the most common billing city.

The number of orders with the most common billing country code.

The number of orders with the most common billing postal code.

The number of orders with the most common billing state.

The number of times the email address was recorded in the last 30 days.

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.

The number of refunds for orders with the email address.

The number of declines recorded for orders with this email address.

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.

Trustworthiness of the shipping email address.

The total monetary value of all of the orders placed by the billing email address.

Use case

A fraudster acquires a stolen credit card—or card numbers and associated data—from the dark web. They attempt to use the card to purchase expensive, easily resalable merchandise like electronics, designer goods, or luxury watches. Or they might use card testing, where they place many small orders to see which cards are active before executing a large fraudulent purchase.

This policy can be used to flag orders associated with a billing email address whose cumulative spend crosses a threshold highly correlated with fraud losses, or to prevent a single high-value fraudulent transaction.

The web browser and version of a device.

The carrier/Internet Service Provider (ISP) of the device is in the list.

The physical country that the device is located in.

The unique identifier of the device.

Device screen resolution based off of our device data collector.

The email address of the consumer that is sent in the request payload.

The IPv4 address of the device. If unavailable, it will be the IP address sent in the request payload.

IP Registering Organization associated with the IP Address.

The login URL sent in a Login API request payload.

The New Account Opening (NAO) URL sent in an NAO API request payload.

The Operating System of the device is in the given list.

The hashed payment token submitted by the client in the request payload.

The physical address sent in the Orders API request payload.

A unique identifier of Device Collection.

The Unique Identifier assigned to a consumer by a client and sent in the request payload.

The Username of a consumer sent by a client in an API request payload.

A custom field sent by the client in an API request payload.

This condition evaluates the distance between the billing address, shipping address, and device location.

.False or TrueHigh Risk IP Org compares the IP org coming from a Login or NAO request with a global list of high risk IP orgs. This condition is evaluated as A true/false response if the IP organization is a high risk.

Use case:

Steps to implement:

Boolean evaluation if the login came from a hosting facility.

Use cases:

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:

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 us by the customer in the Login API (we 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, we gather IP information. The IP address is received from the request to download our device collection SDK — this is the earliest we 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, we are 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, we use 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 we store 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:

Boolean evaluation if IP addresses show anomalous behavior or have been associated with fraud.

Use cases:

Text match to the organization responsible for registering the IP Address.

Use case:

A company has a credential stuffing attack and sees that a specific IP Registering Org is causing the attack. The company then blocks all traffic from that Organization regardless of IP Address.

If the IP registering organization is available.

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.

The calendar date that the purchaser’s account was created.

Use case

A fraudster performs synthetic identity fraud or uses stolen Personally Identifiable Information (PII) to create many new accounts on an e-commerce or financial services platform. Their goal is to maximize the first-time buyer incentives, exploit weak initial credit/spending limits, or quickly purchase easily resellable digital goods (like gift cards) before the platform's long-term fraud monitoring systems fully profile the account. This is a common tactic in bust-out fraud, where the intent is to maximize purchases on the new account and disappear before payment fails.

Use the Account Creation Date to determine how old the purchaser's account is. This age is then used to apply stricter scrutiny to certain high-risk transactions.

The city of the billing address.

The county of the billing address.

If you can ship to the billing address according to Melissa Data.

The street address of the billing address.

Other parts of the street address of the billing address, such as an apartment number.

The type of billing address, such as a PO box.

Checks the billing address against a variety of Melissa Data result codes to verify that the address is valid.

The country of the billing address.

The email address associated with the billing address.

Evaluates the email address against different Melissa Data validation codes for the email status.

Allows merchants to create a rule that will check a mailing address against a variety of Melissa Data result codes to see if the address is valid. Merchants can customize the rule to trigger based on the result codes that users choose.

The country of the billing phone number.

The city of the billing phone number.

The country of the billing phone number.

The billing phone number.

The physical state of the billing phone number.

Checks a billing phone number against a variety of Melissa Data result codes to verify that the number is valid.

The ZIP or postal code of the billing address.

If the billing and shipping addresses supplied by the customer match.

The region of the billing address.

The specific ZIP code type: Standard, Military, PO Box, and Unique.

If the card is credit or debit and PIN capable.

The name of the bank that issued the card.

The brand and type of the card as determined by the BIN.

The highest price of any of the items matching the specified SKU in the order.

Use case

A fraudster attempts to purchase a single, specific, high-demand item—the anchor item—and uses fraudulent means to drive its price down significantly. This differs from the average unit price check because it specifically focuses on the highest-priced unit of a particular SKU, which is vital when a cart contains a mixture of discounted and full-price units of the same item.

Use this policy to verify that the price paid for the single most expensive unit of a high-value SKU is above its legitimate, deeply discounted floor price.

The average unit price of items matching the specified SKU in the order.

Use case

A fraudster or a malicious insider attempts to purchase a high-value item, but they artificially manipulate the final price they pay for it. This can occur through:

Use this policy to flag orders where the final price paid for a specific SKU falls below an acceptable minimum threshold, indicating potential manipulation or unauthorized discounting.

The total price of items matching the specified SKU in the order.

Use case

If more than $500 of a single SKU is in the current order, then hold for review. This might indicate reseller fraud.

The highest price of any of the items matching the specified product type in the order.

Use case

A fraud ring or an individual fraudster targets specific categories of products that are highly sought after, easily converted to cash, or subject to specific resale markets, such as gift cards, electronics, or designer shoes. They might use stolen payment credentials to purchase the most expensive item in that category, often by using a mule account or forwarding the item to an international address.

Use this policy to restrict the purchase of the most high-risk, high-value individual items within specific product categories when other risk indicators are present. This prevents a large, single-loss event related to one expensive item.

The average unit price of items matching the specified product type in the order.

Use case

A fraudster acquires a mass-distributed or leaked coupon code. They know the coupon has a high risk of being revoked if the transactions are clustered, so they try to maximize the financial gain from the most expensive items possible before the coupon is deactivated.

The quantity of items matching the specified product type in the order.

Use case

If more than one sample item is in the shopping cart, hold for review. This might indicate promotional abuse.

The total price of items matching the specified product type in the order.

Use case

If there is more than $500 of face oil in the current order, then hold for review. This might indicate reseller fraud.

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 type of currency used by the customer for the order.

The name of the customer associated with the order.

The unique identifier of the customer assigned by the merchant.

The total input currency amount for the order.

The total base currency amount for the order.

The calendar date that the order was placed.

Use case

If the ticket was purchased today (the order date), the concert is today, and the device location is in a different country than the concert, this is likely fraudulent. You should decline the order.

The type of shipping that was used to fulfill the order. For example, overnight, 2nd day, or standard.

Use case

Use the Order Shipping Type as a key multiplier in your risk scoring. The logic is based on the speed of delivery. Expedited—Overnight, Next-Day Air, or 2-Day Shipping—presents a significantly higher risk than Standard or Ground shipping.

For example, an order is placed with overnight shipping but has a low omniscore. The order is likely fraudulent.

Passes or fails a street address validation.

Passes or fails a ZIP code address validation.

If the status of the card is Authorized.

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 payment brand used to purchase the order, such as Visa.

The BIN number of the payment card.

The country from which the payment card was issued. Also known as a BIN country.

Pass or fail of a CVV validation.

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 type of payment that was sent, such as a credit card.

Whether the payment method is marked as being a prepaid payment method (true) or not (false).

Use case

For recurring orders or subscription services, a prepaid card might be used that has no funds. Due to the processing time, the fraudulent charge is not detected until after the order is completed. Prepaid cards are often used for illicit purposes due to their anonymity, and can be a high risk indicator.

If the billing and shipping postal codes supplied by the customer match.

The city associated with the shipping address.

The county associated with the shipping address.

If you can ship to the shipping address according to Melissa Data.

The street address associated with the shipping address.

Other parts of the street address of the shipping address, such as an apartment number.

The type of shipping address, such as a PO box.

Checks the shipping address against a variety of Melissa Data result codes to verify that the address is valid.

The country associated with the shipping address.

The email address associated with the shipping address.

Evaluates the email address against different Melissa Data validation codes for the email status.

The customer name associated with the shipping address.

Evaluates the customer name against different Melissa Data validation codes for the shipping name status.

The area code of the shipping phone number.

The city of the shipping phone number.

The country of the shipping phone number.

The specific shipping phone number.

The physical state of the shipping phone number.

Checks the shipping phone number against a variety of Melissa Data result codes to verify that the number is valid.

The ZIP or postal code of the shipping address.

The region associated with the shipping address.

The specific SIP code type: Standard, Military, PO Box, and Unique.

The accumulated quantity of a single product.

The total number of items in the cart.

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.

This condition allows you to check of the number of unique values in a Custom Field from the orders in the same Persona as the current order.

Use case 

A customer can see how many different loyalty numbers were used by a Persona, and if it exceeds a reasonable threshold, it can be a significant indicator of fraud.

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.

The sum of all orders declined by the issuing bank in the 14 days before the order.

Matches user selected tags against Account Protection tags.

Evaluates the total weighted score for a chosen tag.

The date that an updated email address from the request payload was first recorded in our network across all customers.

A machine learning model that evaluates the general trustworthiness of an updated email address from the request payload.

The date that an updated phone number from the request payload was first recorded in our network across all customers.

A machine learning model that evaluates the general trustworthiness of an updated phone number.

The number of days since the user account was created. Measured as zero or greater.

Login URL is a text match to the optional LoginURL field that can be passed with a Login API call.

The New Account Opening (NAO) URL is a text match to the optional NAO URL field that can be passed with an NAO API call.

Customers can choose a time of day and add a range before or after that time to create a timeframe.

A custom field sent by the client in an API request payload.

Distinct account change events initiated within a selected time for an Account ID.

The number of times a billing address has been updated for an Account ID.

Counts the number of times a given user ID has received the decision response - blocked.

Counts the number of accounts created using distinct email addresses from a single device.

Counts the number of accounts created using distinct phone numbers from a single device.

Counts the number of distinct cities for a single username.

Counts the number of distinct countries for a single device.

Counts the number of distinct countries for a single User ID.

Counts the number of distinct countries for a single username.

Counts the number of distinct devices for a single username.

Account change events initiated from distinct devices with the same Account ID within a specific timeframe.

The number of unique billing email addresses that placed orders with this account ID in the last 14 days.

Use case

If a user changes their email repeatedly in the same account, this might indicate a high risk for account takeover.

Distinct IP addresses associated with the Device ID.

Counts distinct passwords for a single IP Address.

The number of unique payment tokens that were used to place orders with this account ID in the last 14 days.

Use case

If a user changes their payment card repeatedly in the same account, this might indicate a high risk for card testing.

Counts distinct session IDs for a single username.

Counts distinct User IDs from a single Device ID.

Counts distinct User IDs for a single IP Address.

Counts distinct usernames for a single session ID.

The number of times an email address has been updated for an Account ID.

Counts the number of failed attempts for a single User ID.

Counts the number of failed login attempts from an IP Organization.

Counts the number of failed attempts for a single User ID.

Counts the number of failed attempts for a single username.

Counts the number of times a given user ID has received the challenge outcome - failed.

Counts the number of account creation attempts from an IP address.

Counts the number of account creation attempts from an IP address.

Counts the number of account creation attempts from an IP organization.

Counts the number of phone numbers from an IP organization.

The total monetary value of items matching the specified SKU purchased by the Persona in the last 14 days.

Use case

If an account purchased more than $1,000 of a specific SKU within a 14-day period, then hold for review. This might indicate reseller fraud.

The total monetary value of items matching the specified SKU purchased by the Persona in the last 14 days.

Use case

If an account purchased more than 10 items with a specific SKU in a 14-day period, then hold for review. This might indicate reseller fraud.

Counts the number of login attempts from a single device.

Counts successful and failed login attempts for a single IP Address.

Counts the number of login attempts per User ID.

Counts the number of times a single user attempts (or succeeds) in logging in with many different passwords on a single account.

Counts missing device IDs for each IP organization.

The number of times a name (first name or last name) has been updated for an Account ID.

The total number of orders placed with this account ID in the last 14 days.

Use case

If user signs up for more than five subscription accounts in 14 days, hold for review. This might indicate promotional abuse.

The number of orders placed with this account ID and billing address in the specified time period.

Use case

An unusually high velocity of orders can be a risk indicator for various kinds of fraud, such as card testing.

The number of orders placed with this account ID and this billing email address in the specified time period.

Use case

An unusually high velocity of orders can be a risk indicator for various kinds of fraud, such as card testing.

The number of orders placed with this account ID and billing phone number in the specified time period.

Use case

An unusually high velocity of orders can be a risk indicator for various kinds of fraud, such as card testing.

The number of orders placed with this account ID and this payment token in the specified time period.

Use case

An unusually high velocity of orders can be a risk indicator for various kinds of fraud, such as card testing.

The number of orders placed with this account ID and shipping address in the specified time period.

Use case

An unusually high velocity of orders can be a risk indicator for various kinds of fraud, such as card testing.

The total monetary value of all of the orders placed with this account ID and shipping address in the specified time period.

Use case

An unusually high velocity of orders can be a risk indicator for various kinds of fraud, such as card testing.

Counts the orders by Customer ID.

Counts orders by Device ID.

Counts orders by Email Address.

The number of orders placed by this billing email address and this billing phone number in the specified time period.

Use case

An unusually high velocity of orders have the same email and shipping address. This can be a risk indicator for various kinds of fraud, such as card testing.

The number of orders placed with this billing email address and this payment token in the specified time period.

Use case

An unusually high velocity of orders can be a risk indicator for various kinds of fraud, such as card testing.

The number of orders placed with this billing email address and this billing address in the specified time period.

Use case

An unusually high velocity of orders have the same email and billing address. This can be a risk indicator for various kinds of fraud, such as card testing.

The number of orders placed by this billing email address and this shipping address in the specified time period.

Use case

An unusually high velocity of orders have the same email and shipping address. This can be a risk indicator for various kinds of fraud, such as card testing.

Counts orders by Payment Token.

The total monetary value of orders placed with this account ID in the last 14 days.

Use case

If a user signs up for more than $500 worth of subscription accounts in 14 days, hold for review. This might indicate promotional abuse.

The monetary value of all of the orders placed with this device ID in the specified time period.

Use case

An unusually high velocity of orders have the same device ID. This can be a risk indicator for various kinds of fraud, such as card testing.

The total monetary value of all of the orders placed with this billing email address in the specified time period.

Use case

An unusually high velocity of orders can be a risk indicator for various kinds of fraud, such as card testing.

The total monetary value of all the orders placed with this payment token in the specified time period.

Use case

An unusually high velocity of orders with a high total value have the same payment token. This can be a risk indicator for various kinds of fraud, such as card testing.

The number of times a phone number has been updated for an Account ID.

The total monetary value of items matching the specified product type purchased by the Persona in the last 14 days.

Use case

If an account purchased more than $1,000 worth of lipstick in a 14-day period, then hold for review. This might indicate reseller fraud.

The total number of items matching the specified product type purchased by the Persona in the last 14 days.

Use case

If an account purchased more than 10 lipsticks in a 14-day period, then hold for review. This might indicate reseller fraud.

The number of times a shipping address has been updated for an Account ID. A change from Address A to Address B and a subsequent change back from Address B to Address A is counted as two distinct changes.

Counts the number of distinct usernames with no user ID from a single IP address.

Counts the number of distinct usernames with no user ID from a single IP registering organization.

Percentage of failed attempts with no user ID from a single IP address per the total successful and unsuccessful logins from that IP address. The result of this will be a percentage of bad login attempts from a single IP.

Counts the number of failed attempts with no user ID divided by the total of all successful login attempts from a single IP organization over the given time period. Total successful login attempts include all login API calls and failed attempts from the IP organization.