Less Customer Friction, more 4th of July Fun: Using Arrays in SAS Fraud Management Part 3
In this continuation of a series on SAS Fraud Management user variable arrays, you'll learn how to write a rule to detect travel patterns and reduce false positives for customers.
Let's set the scene on a vacation past, or future. Perhaps you have been driving for two, three, or four hours. This may or may not include bathroom breaks.
False positives can create friction with your customers and negatively impact their experience. Now, let's discuss how you can strategically write rules to discern fraud from family fun, and keep your customers enjoying less friction and more fireworks.
Distance-based fraud rules
So why might a card decline when I am on vacation, or otherwise out of my home area? Financial organizations often use distance-based rules for detecting fraud. For example, a customer spending $300 at their local supermarket is not unusual, but a similar purchase in a city hundreds of miles away is less likely to be legitimate activity. Let's look at a simple rule that declines transactions over $250 if they are more than 50 miles away from the customer's home address.
if hct_mer_mcc = '5411' and
tca_client_amt > 250 and
ZIPDISTANCE(HCT_TERM_POST_CODE,XQO_CUST_POST_CODE) > 50
then do;
%Action.Decline()
end;
In this case we use the merchant category code representing supermarket and grocery store transactions. The rule code declines transactions at merchants like this that are more than 50 miles away from the home zip code, and over 250$.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
This simple approach can be helpful in identifying potentially fraudulent transactions because they don't match typical behavior for the customer. However, a downside of this approach is that we have a high likelihood of false positives if we don't account for times when the customer is legitimately traveling outside of their usual distance radius.
False positives are generally undesirable, but arguably particularly so on vacation - so how can we modify or augment this distance rule so that we more specifically catch fraud and have fewer false positives from typical travel activity?
Identifying travel activity with user variable arrays
In SAS Fraud Management you can create arrays of user variables in order to store and track information about customers. In our first installment of this series we introduced user variables and user variable arrays, and discussed a simple example of utilizing transaction history to make a decision. In the second article we discussed a more complex example: tracking fraud score trends with user variable arrays to reduce false positives.
Now, we'll explore a few ways you can detect travel activity with user variable arrays. In this example we will continue to utilize a few of the user variable arrays we created earlier in the series: specifically variable arrays to track the timestamps and zip codes of the most recent five transactions. We will utilize the location and the time of the transaction in rule logic that will help determine whether activity is legitimate travel, or potential fraud.
This rule will be a variable rule, so it will run before the decision rule we discussed earlier. The following variable rule code declares these user variable arrays and populates them as applicable transactions come in.
/*Declare arrays storing txn information */
%DeclareArray(&rule.txn_zips , _A_TXN_ZIP_1 - _A_TXN_ZIP_5);
%DeclareArray(&rule.txn_dttm , _A_TXN_DTTM_1 - _A_TXN_DTTM_5);
/*shift the arrays and populate the first position with the incoming values*/
%ShiftHistoryArray(&rule.txn_zips &rule.dttm);
%set( _A_TXN_DTTM_1 ) = dhms( rqo_tran_date,0,0,rqo_tran_time );
%set( _A_TXN_ZIP_1 ) = HCT_TERM_POST_CODE;
Now, we would like to add some logic that will detect if the customer is travelling. One way we might do this is by checking to see if the transactions are getting further and further away from the home area. In this case, if the distance from the customer's home has increased or stayed constant in the last 3 transactions, then a travel flag indicates that this customer is potentially travelling.
if ZIPDISTANCE(_A_TXN_ZIP_1,XQO_CUST_POST_CODE) >= ZIPDISTANCE(_A_TXN_ZIP_2,XQO_CUST_POST_CODE) and
ZIPDISTANCE(_A_TXN_ZIP_2,XQO_CUST_POST_CODE) >= ZIPDISTANCE(_A_TXN_ZIP_3,XQO_CUST_POST_CODE) and
ZIPDISTANCE(_A_TXN_ZIP_3,XQO_CUST_POST_CODE) >= ZIPDISTANCE(_A_TXN_ZIP_4,XQO_CUST_POST_CODE)
then do;
%set(_A_AUTO_TRAVEL_FLAG ) = true;
end;
Next, we must modify our earlier distance rule. Instead of declining transactions over a certain distance from home, the rule could use the travel flag to conditionally check the distance. If the customer is not travelling, the rule would function as it did before, but if the travel flag is true, then the rule logic could use the most recent transaction as the new reference point for the customer. In that case, the 50 mile radius around the last known location of the customer is used to accept or decline the transaction.
Of course, in this case, we would still need to worry about the second or third transactions getting approved. Ideally, neither of those would be declined, since this could still lead to some frustration. One way to combat this is to look for a 'secure' transaction - usually a Point of Sale (POS) entry mode like 05. This is an EMV transaction that is very secure, so likely to be indicative of the customer using the card.
The rule could set the travel flag for transactions with an 05 entry mode outside of the home radius, and track the most recent zip code for this transaction specifically. Since this transaction type is highly secure, you can now establish a zip code to that area. As a customer drives further away and does another 05 entry mode, you can update your travel region to the new location, and continue this until the customer has stopped. The travel flag could be reset to False once there is an 05 entry in within the home radius.
Of course, there are many different ways to set and maintain this travel flag. Instead of location and time, you could use particular transaction types associated with travel, like rental car companies, gas stations, and hotels. You could set the travel flag to expire after a predetermined amount of time, or reset once the customer makes a transaction close to their home location again. As we just discussed, you might want to use only select, secure transactions as a reference point for customer location. You also might want to apply travel rules to particular transaction or merchant types depending on their risk and your customer analytics.
In addition to identifying whether or not a customer is travelling, you can craft rule logic to discern whether travel activity is actually possible. One way you could do this is by creating an additional flag for impossible travel. For example, if a customer is travelling by car and stops for gas 150 miles away from their home, it is reasonable that they might check into a hotel several hours late having travelled 100 more miles further from home. Compare this activity to if a customer swipes their card near their home and then minutes later there is a transaction at a supermarket 150 miles from home.
The final decision on whether to decline, accept, or alert on a transaction can be determined using many travel indicators. Analyzing your customer behavior can help you identify these indicators and answer questions about patterns. Different variables, thresholds, and logic
Going Further (literally)
This article has explored just a few ways to gather information using user variable arrays, but there are many other use cases depending on the activity and the information you want to detect.
For example, in this case we focused on a customer who is driving on their vacation and some of our rule logic incorporated the maximum distance that the average customer could get on a single tank of gas. Creating another set of rules is also a possibility to create an air travel flag, which could easily extend this zip code based approach. Each domestic US airport has its own zip code, and customers are unlikely to spend money in an airport unless they are travelling.
Hopefully, this post has inspired you to explore user variable arrays and how they can inform your organization and its rules. If you have any questions about these examples or suggestions for future topics, please reach out!
Check out the other posts in this series here:
Using Arrays in SAS Fraud Management
Spring Cleaning your SAS Fraud Management Rules: Using Arrays Part 2
For more information on SAS Fraud Management, see the user guides and communities.
Find more articles from SAS Global Enablement and Learning here.
