Detecting credit card fraud with Red Hat Decision Manager 7

Red Hat Decision Manager provides a vast array of decision management functionality. From the Decision Tables feature in the new Decision Model and Notation (DMN) v1.1, which implements the full FEEL Compliance Level 3 of the DMN specification, to Predictive Model Markup Language (PMML).

Another powerful feature is the Complex Event Processing (CEP) engine. This engine provides the ability to detect, correlate, abstract, aggregate or compose and react to events. In other words, the technology provides techniques to infer complex events from simple events, react to the events of interest, and take actions. The main difference between CEP and normal rules execution is the notion of time. Where standard rules execution in Decision Manager deals with facts and reasoning over these facts, the CEP engine focusses on events. An event represents a significant change of state at a particular point in time or interval.

Recently, I was asked to demonstrate how Decision Manager CEP can be used in a real-time credit card fraud detection system. One of the requirements I was presented with ended up in an interesting rule implementation that forms the basis of this article. The requirement was defined as follows:

"When a credit-card transaction enters the system, fetch the context of that transaction from a datastore, where the context is defined as an {x} number of previous transactions of the same credit card. When, within the last 15 minutes of the current transaction, there were three or more additional transactions with the same card, and of those transactions, at least two were within 10 seconds of each other, raise a ‘potential fraud’ alert.”

When we look at the requirement in more detail, we can identify some interesting time-based constraints. Let’s analyze them one by one and gradually build our CEP rule. Let’s assume that the logic to fetch the context of the current transaction (the {x} number of previous transactions) from the datastore is given and the transactions have been inserted into the CEP engine.

Constraints

1) Were there four or more transactions in the last 15 minutes?

1-a) This requirement has the notion of a window: a time-based window of 15 minutes, to be more precise, that will capture all the credit-card transactions that happened within that timespan. In Decision Manager, this can be implemented using the accumulate construct with a time-window construct. The accumulate construct is defined as follows:

accumulate( <source pattern>; <functions> [;<constraints>] )

Let's start with the source pattern in which we accumulate all credit-card transactions in our time window:

accumulate ($cct:CreditCardTransaction() over window:time(15m) from entry-point Transactions

This states that we want to accumulate all CreditCardTransaction events from the entry point Transactions that have occurred in the last 15 minutes.

1-b) Now that we have defined the logic to accumulate all transactions that occurred in the last 15 minutes, we need to define the so-called accumulate functions to do something with this data. If we look at the requirement, we can see that we need to implement a constraint that determines whether there were 4 or more transactions in the last 15 minutes. We can, therefore, use the count accumulate function to count the number of transactions in our time window:

accumulate ($cct:CreditCardTransaction() over window:time(15m) from entry-point Transactions;
              $nrOfTransactions: count($cct)

1-c) Now that we’ve counted the number of transactions, we can implement the constraint that checks whether we have four or more transactions in this window:

accumulate ($cct:CreditCardTransaction() over window:time(15m) from entry-point Transactions;
              $nrOfTransactions: count($cct);
              $nrOfTransactions >= 4)

2) The second requirement of this rule is that in the set of four or more transactions, there are at least two transactions that occurred within 10 seconds of each other.

2-a) To fulfill this requirement, we need to have access to the CreditCardTransaction events within our window. We do this by using a second accumulate function called collectList.

accumulate ($cct: CreditCardTransaction() over window:time (15m) from entry-point Transactions;
              $nrOfTransactions : count($cct),
              $list: collectList($cct);
              $nrOfTransactions >= 4)

2-b) Now that we have access to the collection (list) of events, we can start comparing them. We need to check whether two CreditCardTransaction events occurred within 10 seconds of each other. To do this, we use the temporal operator after to analyze the temporal distance between two events. The two constraints look like this:

$c1: CreditCardTransaction() from $list
$c2: CreditCardTransaction(this != $c1, this after[0s, 10s] $c1) from $list

Note that the second constraint defines that the CreditCardTransaction is not the same as the CreditCardTransaction selected in the first constraint and that this event occurred within 10 seconds after the other event.

We can now combine our constraints into the complete left-hand-side (LHS) of our rule:

accumulate ($cct: CreditCardTransaction() over window:time (15m) from entry-point Transactions;
              $nrOfTransactions : count($cct),
              $list: collectList($cct);
              $nrOfTransactions >= 4)
$c1: CreditCardTransaction() from $list
$c2: CreditCardTransaction(this != $c1, this after[0s, 10s] $c1) from $list

Actions

With the constraints implemented, we can now define the right-hand-side (RHS), or action, of our rule. In this example, we will introduce a new fact into the rules engine. This is a concept we call inference. This enables us to define additional rules that define constraints and actions on the newly inferred information/facts/events, thus creating a more complex rule base. Our final rule looks like this:

rule "CC-Transactions last 15 minutes"
when
    accumulate ($cct: CreditCardTransaction() over window:time (15m) from entry-point Transactions;
                 $nrOfTransactions : count($cct),
                 $list: collectList($cct);
                 $nrOfTransactions >= 4)
    $c1: CreditCardTransaction() from $list
    $c2: CreditCardTransaction(this != $c1, this after[0s, 10s] $c1) from $list
then
    System.out.println("\nFound 4 or more cc transactions in last 15 minutes of current transaction");
    System.out.println("And within that collection, there are 2 transactions within 10 seconds of each other.\n");
    PotentialFraudFact potentialFraud = new PotentialFraudFact();
    potentialFraud.setTransactions(new java.util.ArrayList());
    potentialFraud.setCreditCardNumber($c1.getCreditCardNumber());
    potentialFraud.getTransactions().add($c1);
    potentialFraud.getTransactions().add($c2);
    insert(potentialFraud);
end

Note that the System.out.println statements are used for demonstration purposes only; it’s not recommended to use this kind of statements in production rules. Also note that at the end of our RHS, we insert the new PotentialFraudFact into the rules engine.

Inference

Having the inferred PotentialFraudFact inserted into the CEP session enables us to write the following rule that reacts to this fact:

rule "Found potential fraud"
when
    exists PotentialFraudFact()
then
    System.out.println("\n!!!! Found a potential fraud!!!!\n");
end

This rule defines that an alarm is raised whenever one or multiple rules detect a potential fraud. Again, the System.out.println statement is used only for demonstration purposes. In a real rule base, the action of such a rule could be to start a fraud investigation case in the Red Hat Process Automation Manager Case Management engine that:

• blocks the credit card
• notifies the user
• and notifies an agent of the bank of the potential fraud

Demo Project

A demo project that showcases the rules in this article can be found here: https://github.com/DuncanDoyle/drools-credit-card-fraud-detection-demo.

It’s a simple project in which credit-card transactions are defined in, and loaded from, a CSV file. To run the project, simply run the Main class from an IDE (Eclipse, IntelliJ, etc.) or use the following Maven command:

mvn clean compile exec:java

The detection of a potential fraud will be shown in the logs.

Conclusion

The Complex Event Processing engine of Red Hat Decision Manager 7 allows users to implement complex, time-based requirements on streams of data in concise and focused rules that use advanced constructs such as the  accumulate construct, time-window contructs, and temporal operators. We saw that by using techniques such as inference, we can infer new, complex information from simple events, allowing us to write more-advanced and larger rule bases that are still easy to understand by both software engineers and domain experts.

Decision Manager 7 CEP provides an excellent base for a more-advanced real-time credit card fraud detection system when combined with other platforms and techniques such as:

• Red Hat Data Grid/Infinispan for caching of the context of credit cards, providing fast in-memory access to data
• Vert.x to implement asynchronous reactive execution of credit card events coming from a large set of clients from various sources
• Red Hat AMQ/Kafka for ingestion and stream processing of transaction events

We will explore these architectures in future articles.