In this post, we’ll learn how to use arrays to track scoring history and trends in SAS Fraud Management. We’ll learn how to use this information to clean up existing rules to reduce friction and false positives.
Reviewing Arrays and Spring Cleaning
Depending on the hemisphere and latitude you're reading this from, spring is in full swing. With a month to go in the season, there is still ample time for some spring cleaning. It is a time to tidy up and clean out things that are no longer useful - and think beyond the usual suspects of the pantry, attic or garage.
The nature of financial activity and fraud is constantly changing, and it is often worth re-examining formerly useful rules to see if they need to be modified or discontinued. Institutions may have rules that had good performance when initially deployed, but they gradually degraded over time. This can increase false positives and negatively impact the customer experience, as well as challenge operational staff. It is good practice to do some rule performance analysis on a regular basis.
In a previous post, we introduced the concept of user variable arrays and how you can use them to write fraud detection rules in SAS Fraud Management. In this second installment of the series, we'll explore two ways user variable arrays can enable you to create more sophisticated rules that reduce false positives and customer friction.
Track score history with arrays
To review, user variables and arrays comprised of them enable historical information to be stored between transactions so that fraud management can make a decision using that historical context instead of each discrete transaction. For more information on the basics of creating user variables and declaring them as arrays and maintaining them, see part 1.
In our example, we have a model that calculates a particular fraud score depending on a transaction. We might have an existing rule that simply alerts on all transactions that score in a medium risk score band:
If rrr_score_1 >= 790
And rrr_score_1 < 850
Then do;
%action_alert;
End;
The false positive might be with in the performance range, but if the operations team is a little short staffed or an unusually high volume of alerts is generated, they might not be able to keep up with the alert volume.
By creating an array to track the scores associated with the most recent 5 events, we can modify the existing rule logic from just alerting all transactions at this medium score band to take a more strategic approach.
After creating the required user variables, we can declare them as an array using a variable rule with code like:
%DeclareArray(&rule.txn_dttm , _A_TXN_DTTM_1 - _A_TXN_DTTM_5);
%DeclareArray(&rule.txn_score , _A_TXN_SCORE_1 - _A_TXN_SCORE_5);
You may recognize the first array from the examples in the first post. Similarly, the score array will store the scores from the last 5 events. The variable rule's logic populates each array every time a transaction comes in.
%ShiftHistoryArray(&rule.txn_score &rule.dttm);
%set( _A_TXN_DTTM_1 ) = dhms( rqo_tran_date,0,0,rqo_tran_time );
%set( _A_TXN_SCORE_1 ) = RRR_SCORE_1;
The first line shifts the items in the array by one. Then each subsequent line populates the now-empty first position in the array with the new value reflecting the most recent transaction.
Remember, this variable rule will run first, so that it will set up the array appropriately before the action rule that generates the alert runs. There are many ways you could augment the rule logic for the medium score band using this information, but we will focus on two examples here. These examples use the quantity of transactions in a particular time frame and the historical trend in the score
Example 1: Multiple transactions in a timeframe to alert
For example, let's say that we no longer want to alert on the first transaction that scores in the medium risk band. Since we are tracking the last 5 events, we can effectively monitor a particular account to see what happens next, and then decide whether to alert based on that.
For example, if this one transaction is the only one that the customer does, and does not make another transaction within the next hour or other designated time frame, does this transaction still need to be alerted? Potentially not, and this is an opportunity to reduce volume.
On the other hand, if another transaction comes in within the next hour, and it also scores in this medium band, that might be the trigger to now generate an alert.
Rule Logic would look something like this:
if _A_TXN_SCORE_1 >= 790
and _A_TXN_SCORE_1 < 850
and _A_TXN_DTTM_1 - _A_TXN_DTTM_2 <= hms(1,0,0) and _A_TXN_SCORE_2 >=790
and _A_TXN_SCORE_2 <850
then do;
%action_alert;
end;
In this version of our action rule, an initial transaction with a score of 800 would not generate an alert. However, if there was another transaction 10 minutes later and it scored 810, an alert would be generated.
Of course, you still might want to consider other factors, such as amount or high-risk areas, but this is one basic option to manage volumes and false positives by looking at historic activity.
Example 2: Score delta threshold to alert
Now we will look at a different way to strategically modify the action rule logic using the historical data stored in the array. Let's say that we want to consider transactions that score in this band in the context of how that score is changing.
Now, we are looking at the score delta value between the current and prior event. This might help us identify where the model is potentially seeing an elevated risk with the customer’s purchases. As initially indicated, just because something scores in a medium band might not necessarily mean it’s risky initially, but sometimes the model might pick up on something and elevate the score significantly in a short period of time. By performing an analysis on our data, we may know the model has better predictability when we see significant score jumps.
For example, if the current transaction score is 795 and the previous transaction scored 150, the difference between the score is quite significant in a short period of time. On the other hand, if the current transaction scores 795 but the previous transaction scored 725 this might not be as indicative of overall risk on the account, since the model did not react in a significant manner. Thus, we can reduce false positives by waiting to see if the score remains elevated before generating the alert.
Consider this simple rule code example:xx
if _A_TXN_SCORE_1 >= 790 >
and _A_TXN_SCORE_1 <850 and _A_TXN_SCORE_1 - _A_TXN_SCORE_2 >= 600
then do;
%action_alert;
end;
With this version of the action rule, if transaction scores in the medium risk band and the score represents an increase of 600 or more since the last activity, an alert is generated. If instead, the score has decreased, or increased by less than 600, an alert is not generated.
More possibilities with arrays
In this example, we showed two ways you can use behavioral history stored in user variable arrays to strategically modify your rules and increase their performance
We could use these arrays in lower risk score bands and watch activity for longer by using the full length of our declared arrays to look at more than the most recent past event. We could use a moving average to assess the trend in score, or incorporate both a time threshold and a score delta threshold based on risk tolerance or other potential factors like how old the most recent activity is.
For example, if the most recent transaction score represents an increase by 520, and the most recent 2 activities were in the last 15 minutes, we might be more inclined to alert on this activity. On the other hand, if it has been over 2 hours since the last activity, we might know that this is less likely to be indicative of fraud based on the model performance.
In short: there are many more ways you can use arrays, and I hope this post has inspired you to explore them!
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 further reading about SAS Fraud Management, check out the user guides and communities.
Find more articles from SAS Global Enablement and Learning here.
