Subscribe to our blog
Get ahead with our award-winning insights on the latest developments in the fraud and compliance landscape. Enter your email below to receive our blog posts directly to your inbox.

Dating back a couple of decades when ecommerce started, one of the first tools to identify online card fraud were velocity rules. Velocity rules measured the number of transactions that were performed by a particular credit card in a (short) period of time. For example, it is unusual, if not impossible, for an individual to perform 10 real transactions in a minute. In the world of fraud prevention, certainly, something to worry about.

Velocity rules are ubiquitous in online fraud prevention. Every fraud prevention system, no matter how simple, has a version of velocity rules. Even modern machine learning models, applied to fraud prevention and risk detection, are informed by velocity features.

Spoiler alert! What velocity is really trying to assess is behavior. But, you probably knew that already.

As time has progressed and the ability to track user behavior has become the basis for all ecommerce marketing, fraud prevention techniques have advanced as well. Now, multiple parameters from historical behaviors are being used like purchase patterns, seasonality, amount history, geolocation, time of day, etc.

The IdentityMind platform offers multiple ways of using the history of an identity to inform the risk assessment process:

  1. Reputation. A very accurate measure of the likelihood of risk of a given identity. An identity that is identified as Trusted (the highest level of reputation) in the system, is later associated with fraud/risk only 0.03% of the time. To put this into perspective this represents 0.002% of the amount of losses associated with chargebacks. The reputation in the IdentityMind platform is the result of heuristics, deterministic and statistical models. These models are informed by the history of the transactions and the results of the evaluation of those transactions within the IdentityMind ecosystem. There are three additional levels of reputation: Suspicious, Bad, and Unknown. While Suspicious and Bad have similar accuracy measures, Unknown is when there is not enough behavior in the system to calculate an accurate reputation score.
  2. Graph Score. The graph score is a measure of the identity risk based on the complexity of the attributes that make their identity as they are correlated to many other attributes and other identities. This score is the result of supervised machine learning algorithms. A high score is usually a good indicator, while a low score is considered risky. You can learn more about our graph score here and by watching our Graph Intelligence Demo:
  3. Security Tests. The security tests are factual risk factors. We have over 40 security tests that calculate whether a transaction has passed the limits of established thresholds for, say, velocity. We have tests that can measure either the number of transactions or the aggregated amount associated with transactions performed by the same identity. Security tests in general, within the platform, are simple to configure and use.
  4. ARPThe automated review policy is a mechanism within the platform to accept transactions. One of the ARP models measures users’ consistent good behavior as a way to accept transactions that, while considered risky, are associated with users in which that specific behavior is considered acceptable. You can read more about ARP and its models in this previous post.

Now, as advanced as the platform is in the use of historical data, the security test infrastructure (with over 400 security tests) is a bit rigid in the sense that our development team can only add new tests to it. These are usually not hard to add, but it does require involvement from our team.

Part of the reason for this rigidity is to ensure that the platform can continue to perform in real-time. No matter how complex, all transactions are evaluated in real-time and the platform has to perform in milliseconds.

One of the real issues we face as we onboard new clients that are moving away from their fraud prevention systems is to provide tools with comparable models (e.g. rules) to the system they had in place. In a way, you (and I mean we) always have to demonstrate you can start from the same baseline, and then grow to whatever other paradigms and tools our platform offers. These may require specific evaluation of historical transactions, in specific ways. This is where the rigidity of our security tests was disadvantageous.

As a result, we are introducing a more flexible way to setup velocity rules in eDNA to use the historical transactions associated with a user.

New and Improved Historical Transactions Security Tests

We are introducing two new parameterized security tests: one to count transactions in a period of time (ED:543), and another to aggregate the amount (ED:544). We recently covered these two in a webinar. Here is the video clip:


ED:543. Transaction History: Transaction Count.

This security test counts the number of transactions, including the transaction being evaluated, associated with the identity (either with the source or destination) that meet the specified criteria in a specified time period. The configuration for the security test looks like this:

Let’s review the parameters:

  1. Entity. This is to select which entity of the identity is used for the velocity calculation. In some instances, the device may be an indication of an account takeover for example. At the time of this write up only “User” is available, but in the near future other entities will be available (e.g. device, payment instrument, IP address).
  2. My Transactions. You have the option of looking at transactions that this identity performs with you, or across all of our IdentityMind clients. In some situations knowing what an identity is doing across the IdentityMind client base may be an indication of identity fraud, or that the identity is being used as part of a fraud ring. As a client of ours has pointed out, the difficulty of using information coming from the IDM client base is that fraud analysts cannot see the details of those transactions and therefore makes it difficult to justify their decision during the manual review process.
  3. Feedback Type. This is the ultimate decision of the transaction as it sits in the database of our platform. You can use it, for example, to count the number of transactions that have resulted in only chargebacks, or count all the transactions that an identity has performed.
  4. Digital or Physical. This ties directly into the API field “vg” (virtual goods). This flag is used to distinguish whether the goods that are being purchased in a transaction are virtual goods like a virtual sword, a license key, a gift card, or whether it is a physical good, like a pair of shoes, or a mobile phone. If you are a merchant or a marketplace that deals with both types of goods, the risk considerations are quite different, and the behaviors of the identities that deal with one or the other may be quite different;  isolating behavior may be relevant.
  5. Period. Simply the period of time to look at. At the moment you can go from 1-24 hours, or from 1 to 180 days. Remember, real-time is the key.
  6. Originator or Beneficiary. In our platform there are two types of transactions where this type of behavior is useful to analyze: Payments and Transfers. Payment transactions only have one user, the buyer. Transfers are applicable to both movement of money (like a remittance) and to marketplaces where you have a buyer (originator) and a seller (beneficiary). If you are analyzing payment transactions then only the originator makes sense; if you are using transfers, then you need to choose which identity to count in the transactions. This option would not make sense in KYC, KYB or Login transactions.
  7. Payment Status. This may be tricky to use and it depends on your API integration. This refers to whether the payment (e.g. credit card, ach) has been accepted or declined by the bank. To use this option your integration must indicate the status of the payment. You should leave blank if you have not integrated payment status with us. For example, if you are dealing with payment methods for which there is no concept of accept or decline like stored value, or gift cards, or coupons, do not use this option. This also does not make sense when choosing a transaction type of KYC, KYB or Login.
  8. Policy Result. This looks at the actual result of your fraud policy for a given transaction. For example, if you have check for “Manual Review”, it will count those transactions that resulted in manual review by the policy, even if a fraud or risk analyst may later have accepted or rejected that transaction. To look at the post evaluation of a manual reviewed transaction, you need to look at the feedback.
  9. Transaction Type. This refers specifically to the type of transaction you have integrated through the API. Remember that there are three types of transfers: transfer, funding (transfer in) and withdrawal (transfer out).

ED:544. Transaction History: Aggregated Amount.

This security test adds the total amount (API field ‘amt’) of the transactions, including the transaction being evaluated, associated with the identity (either with the source or destination) that meet the specified criteria in a specified time period. The configuration for the security test looks like this:

The configuration parameters are exactly as ED:543 with the following exception:

The transaction type only lists those that have ‘amt’ in the API specification: Transfer, Transfer In (Funding) , Transfer Out (Withdrawal), and Payment.

Examples

  1. Simple Velocity. In the following example I want to alert when a buyer has performed 3 successful transactions in the last hour.

  1. Reviewed and Accepted. Let’s assume you have a user that looks suspicious but you do not want to review it again if it has previously been reviewed and accepted.

  1. Velocity but only when above certain aggregated amount. You can combine both security tests to create more complex scenarios.

  1. Card Testing. There are many ways to apply card testing, but in general, a good assumption would be velocity on rejected transactions. One possible configuration looks like this (there are other security tests that can also catch card testing)

Coming Up

  • (soon) There will be additional parameters as we make sure the infrastructure continues to perform at the expected rates. For example, type of card (e.g. prepaid, credit, foreign) is coming soon.
  • (soon-ish) At the moment there is only one version of the security test per rule, so if you need two counts of transactions with different parameters, you still need to write two rules.
  • (not-so-soon) A version of this for the edna graph.

Feedback

If there are situations that you think would be useful for your use case, please let us know… or if you are unsure how to use it for a particular scenario… reach out.