How To Detect Anomalies in Payment Transactions

How to Detect Anomalies in a Sequence of Transactions

‍

"Finding anomalies in transaction data is really the classic way to detect fraud.

‍

If we look at legacy solutions from fifteen to twenty years ago, organizations would not have been able to profile a user. There was no way to understand how users behave in certain situations—let alone act on that information.

‍

About ten years ago, solutions were finally able to allow teams to perform some form of profiling. Organizations could take certain pieces of data, such as payment methods, MCC codes, unique activities, and use that information to profile users. Teams could then write rules based on these profiled users to protect themselves from these instances of fraud.

‍

However, what we’re doing today with Unit21 is basically allowing customers to run rules with essentially any look-back period. Your historical data is all there, and we empower you to look back at any historical period you want. With this capability, teams no longer need to profile users, because all of your historical data is available. Our rules engine works by knowing how to go back and look at the specific activity that you are trying to detect and understand, allowing you to see how the user has been interacting so far.

‍

For example, let’s say you want to flesh out a customer who suddenly starts depositing a lot of cash, seemingly injecting it into the system. It’s very easy to use Unit21 to understand how this person was doing this in the past, and you can even set up triggers to flag this type of anomalous behavior for review.

‍

‍

Using Historical Deviation to Detect Current Anomalies

One of the best tools in our toolkit for detecting anomalies in payment transactions is using a historical deviation model.

‍

Unit21’s tool has a couple standard models for deviation that are available and can be configured to your specific parameters. You can adjust a number of variables to create a rule like the following:

‍

• Look at all entities with more than 3 transactions having a sum of amounts greater than $500 in a 1 week period, differing by more than 2 standard deviations greater than the mean, compared with its average transaction amount over the prior 30 days.

‍

We also have another historical deviation model that’s a little simpler. Using it, we can create a rule like the following:

‍

• Look at all entities where the deviation between transactions in the last 3 days compared to those in the last 14 days have summed greater than 150%.

‍

All of the individual factors in these rules can be fully configured, giving teams an immense amount of control over what they can monitor for. These rules can also be filtered, to narrow your focus. For example, these rules could be filtered to look only at cash transactions. With this ability, teams can really hone in on specific data to monitor more closely for patterns.

‍

As you can see from the demo, it’s extremely easy to write and configure these rules, as well as make updates as needed. These rules are ideally suited for looking for patterns of behavior that are unusual for an individual user.

‍

Another useful model—especially when used alongside a historical deviation model—is one that looks at the top transacting entities. Take the same payment type or channel you were analyzing with your deviation rule, and look at the same look-back period to analyze the top transacting entities during that time.

‍

By regularly looking at the top transacting user, you can get a baseline for normal transacting behavior. If the top ten look good on any given day, you likely don’t have much to worry about. Having this baseline makes it much easier to understand how users are interacting with your platform, and empowers you to more readily identify anomalies in behavior.

‍

‍

Interested in seeing how this works first-hand? Check out our first session of Fraud Office Hours on-demand for a quick demo of Unit21's software:

‍

‍