Building a Profile with SAS Fraud Decisioning
In this post, you'll learn how profile variables enable you to go beyond individual transactions when using SAS Fraud Decisioning to detect financial fraud. We'll discuss how profile variables are created, managed, and referenced in rules.
For fans of Criminal Minds, a 'profile' is certainly familiar. The profile helps the team identify whether behavior matches what is expected from the 'unidentified subject'. The Behavioral Analysis Unit uses the profile to discern what is typical behavior from what is suspicious. The profile is powerful because instead of reacting to the suspect's moves one at a time, the team can view them in context, and predict the next moves of the suspect. Though our setting is very different, it is not unlike the profile we will discuss in this post.
Instead of hunting serial killers, we will be discussing financial crime. Instead of discerning bystanders from Unidentified Subjects, we'll use our profile to differentiate typical customer activity from fraudulent activity. In this post, we'll discuss the basics of profile variables, then explore an example of how to create, populate, and utilize one in a rule.
So what is a profile in SAS Fraud Decisioning? Profiles include information about customer behavior that you can use in rules.
In Fraud Decisioning, each line of business has its own organization, and the organization has an associated profile schema. For example, if your environment uses an organization called Banking Fraud, the associated profile variable schema is called the Banking Fraud profile.
Within the profile schema, you can create profile variable sets. Profile variable sets are grouped by a particular variable. This variable is used to associate transactions together, which is what enables profile variables to store information over successive transactions related to the same entity.
For example, let's say your institution creates a profile variable set called Customer, grouped on the customer identifier field. This means that messages with the same customer identifier field are grouped together and considered as part of the same entity for the purposes of calculating the profile variables in this set.
Here, we create the Customer profile variable set. The key field is the customer.identifier field.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Each relevant piece of data relating to the customer is stored in a profile variable. Like rules, profile variables are associated with projects.
Let's say I wanted to track the last time each customer changed their account information. First, I create a profile variable called Password Change Datetime (PasswordChangeDtTm) in my project.
This variable will store the date and time of the most recent password change, and it has the type Timestamp.
The Password Change Datetime variable is type Timestamp and will store the most recent
date and time of each customer's password change.
Next, I'll write a rule that will update the profile variable when it is appropriate. This rule example will be a variable rule - a rule that can update a profile variable but not send a decision or alert recommendation. (The second kind of rule - a decision rule - can also update profile variables, as well as send alert and decision recommendations.)
When writing rules that update and use profile variables, keep in mind that variable rules always run before decision rules.
Here is an assignment statement that stores the datetime from the incoming message in the password datetime change field. message.request.messageDtTm in the
profile.Customer.passwordChangeDtTm = message.request.messageDtTm;
However, our rule code also needs to check the message demographic type and only store the message's datetime when the customer is changing their password. If it is the string PWD, it indicates a password change, and we need to set the profile variable password change datetime equal to the message's datetime. Here is the final variable rule:
if message.demographic.type = 'PWD' then profile.Customer.passwordChangeDtTm = message.request.messageDtTm;
Now, when an incoming message is identified as a password change, the datetime of the message is saved to that profile variable. Each unique customer identifier will have a password change datetime associated with it. If the customer has not changed their password since this variable rule was deployed, they will have the default value.
Now that we've collected this information, let's use it in a decision rule.
Let's say we want to create an alert when customers make a large transaction within 24 hours of a password change. This decision rule will create an alert if two conditions are true: the message datetime is within 24 hours of the most recent password change, and the amount is over 30% of the account balance.
if message.request.messageDtTm - profile.Customer.passwordChangeDtTm < dhms(0,24,0,0)
and message.payment.amount >= 0.3 * message.debitaccount.availableBalance
then do;
detection.Alert();
end;
Even this simple example shows how profile variables let you consider customer history instead of each transaction independently when writing rules. This facilitates a more informed decision than using a single transaction alone. A rule that declined all transactions greater than 30% of the available balance might be far too restrictive if it was applied to all customers, but for customers who have recently changed their password, extra caution might be warranted for certain transaction types.
There are some extra factors to consider when you use profile variables in rules. It is important to consider how the profile variable will work on an ongoing basis, but also initially, before the variable rule has had a chance to populate it. You can do this by planning accordingly when writing rule logic, configuring default values, or both.
For numeric profile variables, it is best practice to add a default value. This can help prevent unexpected results when rules are executed before a profile variable has been populated with data. In this case of this datetime value, we might add a default value of January 1st, 1960, which corresponds to a zero in the SAS date format. In our example, for customers who have not changed their password since the rule and profile variable were implemented, no alerts would be generated.
Impact analysis allows you to test the implications of a rule before promoting it to production. Currently, if an impact analysis is run on a rule that utilizes a profile variable, the impact analysis recalculates the profile variable. When selecting a time frame for the analysis, the dates that have messages corresponding to rules with profile variables are underlined.
Looking for more information about Fraud Decisioning?
Check out this post for more on writing rules in Fraud Decisioning on writing rules in Fraud Decisioning.
Read about the key differences between SAS Fraud Decisioning and SAS Fraud Management here.
For more information on writing rules, reference the SAS Detection Architecture Rules Authoring Guide and the DS2 programming guide.
Have a comment, question, or idea for an article? Please comment below or reach out via email.
Find more articles from SAS Global Enablement and Learning here.
