Creating Rules in SAS Fraud Decisioning

[#1]

SAS Fraud Decisioning is a powerful solution for combatting several fraud types, and rules are a key part of what makes this solution so powerful. In this post, you'll gain an introductory knowledge of rules in SAS Fraud Decisioning, and look at an example of creating a basic rule.

Properties of Rules

In SAS Fraud Decisioning, a rule is the business logic of decisioning, represented in DS2 code. You can also think of rules as a set of conditions that determine when an alert should be generated. Rules are applied to incoming transactions to gather information and/or take actions in order to detect fraudulent activity.

To create a new rule, you'll need to specify some properties of the rule, starting with the project you'd like to create the rule in. You'll also need to identify the type of rule, a name for the rule, and the message schema and classifications the rule is associated with.

Rules in Fraud Decisioning are created in projects. You can think of a project like a collection of specific rules, profile variable sets, and other related information. A project can be configured to group all the rules applicable to a particular fraud type or channel.

Next, you'll need to select the rule type. There are two types of rules: Variable Rules, and Decision Rules. Each type of rule has its own purpose and associated methods.

Variable rules update profile variables using information from a message. Earlier, we discussed an example of using a profile variable to track how many times a debit card has been used without a PIN entry. A variable rule might store this information, so that it can be used as part of later transactions, even if no action is needed on that particular message.

Decision rules can take an action on a transaction. Decision rules can utilize multiple variable rules as part of the decision-making process. For example, a decision rule could use the value of several profile variables, like the number of uses without a PIN and whether the ZIP code is typical for the debit card user, to make an alert recommendation.

Decision rules can also update profile variables, but a variable rule cannot take an action on a transaction. Therefore, if you want your rule to do both, you should select the decision rule type.

Next, a rule is associated with a message schema. The message schema defines the expected format of the message that the rule will apply to. This message schema determines the message variables that are available for decisioning in the rule. Depending on the use case, your environment might use an out of the box schema, or you might use a custom schema.

Finally, a rule must include a message classification. The message classification determines which rules are applied to which transactions. Rules can only be associated with a message classification node at or below the level of the node their project is associated with. One message classification node can be associated with many rules.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

In this example message classification tree, if a project is associated with the Americas node, the rules in the project could either be associated with the Americas node, the North America Node, or the South America Node.

Before we move on to the rule code itself, let's look at an example:

In this example, we are creating the rule in a project called Debit Card Fraud. The rule type is Decision, and the message schema is Card Fraud. The rule is called Basic Max Transaction Rule. The message classification is GLOBAL.

Rule Code

Once you have specified the required properties for a rule, you can begin coding.

Rules have four stages in their life cycle. All rules begin in the coding phase, but when they are ready, a user with the appropriate capabilities can move into Testing, Production, and finally Recycling when they are no longer useful.

You may be familiar with writing rules in SAS Fraud Management. While DS1 code is used to write rules in Fraud Management, rules in Fraud Decisioning are written in DS2. For more on the differences between these two solutions including several code examples, see this post.

The code editor allows you to view and automatically populate message schema variables, profile variables, advanced lists, and other resources that you might want to use in creating your rule code.

if message.debitcardfraud.amount >= 10000 
then do;
   detection.Decline();
end;

In this example, I have added a simple rule that will decline transactions over a certain amount. The required information from the message is stored as the variable message.debitcardfraud.amount. A transaction that satisfies this if then condition by having an amount over 10,000$ will make the rule decline the transaction with the detection.Decline() method.

Once a rule code is finalized, a qualified user can promote it to Testing, and eventually, Production. Finally, deploying changes to Production rules will activate them, and they will begin to apply to incoming transactions.

Hopefully, this basic rule example has been informative and inspired you to think about how you can write rules to meet your own business needs. For more information on writing more complex rules, reference the SAS Detection Architecture Rules Authoring Guide.

Find more articles from SAS Global Enablement and Learning here.