What is the difference between SAS Fraud Management and SAS Fraud Decisioning

This post will compare and contrast two SAS Solutions that can identify and prevent payment fraud in real time: SAS Fraud Management, and SAS Fraud Decisioning.

SAS Fraud Decisioning and SAS Fraud Management are payment fraud solutions that financial institutions can use to process 100% of incoming transactions in real-time. Both can provide financial institutions with a way to apply rules and advanced analytics to incoming transactions to detect and prevent potential fraud. Both can be used to detect potentially fraudulent activity for monetary and nonmonetary transactions. They can generate alerts that represent potentially fraudulent activity, while balancing the need to reduce customer friction.

There are also some key differences between these two solutions, including their underlying structure. The solutions also vary somewhat in how the users of each write rules and work and manage alerts.

Architecture

Fraud Management enables fraud detection on a unified single platform. It runs on SAS 9.4 and can be installed on-premises, or in the cloud. While SAS Fraud Management is monolithic, SAS Fraud Decisioning is modular. Fraud Decisioning is cloud-native and based on microservices and containers, so it is more flexible than Fraud Management when integrating into other systems or scaling up and down to rapidly accommodate business needs. This is particularly true if Fraud Management is installed on-premises. The architecture of SAS Fraud Decisioning is easier to scale up or down as needed, and is priced on a per transaction basis.

SAS Fraud Management and SAS Fraud Decisioning both support authoring rules and alert triage. SAS Fraud Management includes three user interfaces in one - Rules Studio, Analyst Workstation, and Manager's Workbench. Different areas of the UI are available depending on the user's role and capability. SAS Fraud Decisioning uses the Detection Definition interface to design, manage, and test rules, and has a separate Alert Triage interface.

Under the hood, SAS Fraud Decisioning leverages other SAS components, including Intelligent Decisioning. Both use a variation of Business Orchestration Services (BOSS) to enrich transaction messages and ensure their specifications match the requirements of each solution.

Fraud Management and Fraud Decisioning required different 3rd party software elements to run. SAS Fraud Management requires Elastic Search and Java. SAS Fraud Decisioning requires Redis, Kafka, and Postgres.

SAS Fraud Decisioning is a next generation, forward-looking solution. In addition to its scalability and ability to integrate with other SAS elements, it has even more flexibility and functionality. For example, Fraud Decisioning enables the use of BYOL ('bring your own language') models, consortium models, SAS custom models, and automated model generation. Fraud Decisioning has CI/CD releases with new features, updates, and out of the box functionality added every month.

Writing Rules

Fraud Decisioning and Fraud Management both enable users to write, edit, and test rules to be applied to incoming transaction. In both, rules have 4 phases in their life cycle:

Coding
Testing
Production
Trash/Recycling

Fraud Management has two types of rules: Variable rules and Action rules. The former updates a user variable, so that information can be stored and used for subsequent transactions. Action rules can return a decision, including whether to decline the transaction.

Similarly, Fraud Decisioning has two types: Variable rules, which update the value of a variable, and decision rules, which return a decision. Rules in Fraud Decisioning can utilize profiles and lists to incorporate data from previous transactions or other sources.

Rules in Fraud decisioning use variables from message schemas, which define the structure of incoming transaction messages. Rules must be associated with projects, and a particular classification of incoming messages to which they will apply. The core message schema includes fundamental required values. At the time of this posting, Fraud Decisioning includes message schemas out of the box for credit and debit card fraud as well as payments fraud, but more use cases are planned and include application fraud and identity fraud. You can also create your own message schemas, and reusable schemas can be combined with other schemas to create a composite message schema.

Rules in Fraud Management use variables from the message layout, which is organized into transaction components. The components store information associated with the transaction. For example, a system component stores fundamental information required by SAS Fraud Management. The customer component stores customer information.

The rules in each solution are written in a different version of data step code. While Fraud Management uses DS1, Fraud Decisioning uses DS2. DS2 utilizes methods in lieu of macros. In DS2, variable names are referenced using the source in addition to the variable name.

if ((RRR_AMOUNT > 5000)
   & (HCT_TERM_CNTRY_CODE in ('840')))
   then do;
      %Action_Alert();
end;

Let's look at an example of a similar rule in each solution and compare the syntax. This rule issues an alert if the transaction has an amount greater than 5,000, and the merchant country code is 840. The DS1 example above uses the %Action_Alert() macro to issue the alert, while the DS2 example below uses the detection.alert() method. Ds1 references values from segments - ex, "HCT_TERM_CNTRY_CODE", while the DS2 variable names reference the message, schema, and variable: "message.merchant.country".

if
   (message.cardfinancial.amount > 5000.00) and
   (message.merchant.country = '840')  
then 
   detection.alert();

Working Alerts

Now let's compare how each solution organizes alerts and how users work on them. While Fraud Management analysts work alerts in the Alert user interface, Fraud Decisioning has the separate Alert Triage interface.

In Fraud Management, alerts are organized in business units, strategies, and queues. Business units are also called rule domains.

In Fraud Decisioning, alerts are similarly organized, within domains, triage types, and queues.

Hierarchal alert organization in SAS Fraud Management and SAS Fraud Decisioning.

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

Fraud Management users with manager or administrative roles use a dedicated section of the UI called Manager's Workbench. Fraud Decisioning is currently configured using REST API requests.

Fraud Management analysts can work in outbound mode processing existing alerts, or accept incoming calls and work alerts in inbound mode. Working in outbound mode can involve priority or direct servicing. In priority servicing, an analyst is automatically assigned the highest priority alert in all of the strategies they can access. In direct servicing, they can select a strategy, and are automatically assigned the highest priority alert it contains. See this post for more information on working in inbound vs outbound mode in Fraud Management.

Both solutions enable priority and direct servicing, and it works similarly in Fraud Decisioning with triage types, which are roughly equivalent to strategies. In priority servicing, the system identifies the highest priority triage type and queue within that triage type that the analyst can access, and assigns the highest priority alert from that queue. In direct servicing, they can select a triage type, and are assigned the highest priority alert from the highest priority queue. Notably, these alerts will not necessarily be the highest priority alerts across the entire system, since the system assigns the alerts by the priority of the triage type, then the queue, then finally the alerts within that queue.

SAS Communities Library