“Superficial” vs. “Inherent” Fraud Detection Rules

August 30th, 2011

There are two types of rules, “superficial” rules and “inherent” rules. Superficial rules are easier to create and they are straightforward to understand, e.g., transactions happening at certain retailers. These rules may be good for a few weeks and their performance drop quickly. Inherent rules capture more time lasting ( and usually hidden and mutli-dimensional) patterns of fraud behaviors. To create them,we may have to use more sophisticated methods including predictive modeling. The PRM SQL statements for some of these inherent rules that we created have 5,000 characters. These rules work like magic and have very low false positives.

Detection of Common Point of Compromise

August 1st, 2011

About 25% of compromised good cards identified by BDM will have fraudulent activities within the next 3 months. (In comparison, usually about 1% of cards alerted by a popular point of compromise (POC) service from a big company have fraudulent within 12 months.) The common points of compromise detected by BDM are highly accurate. Identifying POC accurately  and early and reissuing cards provide the following benefits: 1. It is better than real time fraud detection because the fraud loss can be stopped before it happens; 2. Reissuing cards  is less intrusive to good customers than blocking suspicious transactions.

Every BDM rule alert stops $32 additional debit card fraud

March 13th, 2011

Based on the actual debit card fraud detected by BDM rules since June of 2010, every alert generated by BDM rules stops $32 fraud. The following are some facts about the BDM rules. (BDM stands for Business Data Miners.)

1. $32 is the total dollar amount of debit card fraudulent transaction actually stopped by blocking cards divided by the total number of alerts generated by BDM rules.

2. $32 does not include fraud transactions detected by existing non-BDM rules. For example, if both existing non-BDM and BDM rules alert on the same card and an analyst  blocks it, the fraud loss prevented is excluded from $32.

3. The total additional fraudulent transaction amount prevented due to BDM rules is multiple million dollars annually.

4. There is no increase in operation cost at all. This is because: a. the volume of alerts generated by BDM rules is less than 10% of total number of alerts; b. we helped the client identify ineffective rules and retire them.

5. BDM rules are not only statistically accurate but also understandable. For example, we have BDM rules targeting on risky retailers, risky MCC and risky cities.

6. BDM rules are written in standard SQL statements that can be deployed  in many fraud prevention products.

7. BDM rules are refreshed monthly based on latest transactions and fraud information.

In fraud prevention analysts’ own words, “these BDM rules are amazing”.

Neural Networks and Fraud Prevention

February 17th, 2011

Neural networks have been widely used for fraud prevention in banking industry. But there are many predictive modeling technologies that are far more powerful than neural networks. We have consistently detected more frauds using  methods other than neural networks.

BDM’s Debit Card Fraud Detection Rules Won A Contract With One Of Top 15 Banks

September 27th, 2010

BDM signed a contract with one of the top 15 banks in America to provide debit card fraud detection rules. In a head to head competition, BDM’s rules detected far more frauds given the same number of alerts based on historical data than competitors did.  BDM rules were deployed into production and have screened almost 200 million debit card transactions in real time. They have delivered solid results and achieved annual ROI of 1,000%.   BDM rules are unique in that they detect fraud with extremely high accuracy statistically while they are interpretable by fraud prevention staff.

Our new debit card fraud detection rules perform well in production.

July 9th, 2010

For testing purpose,  they generate only 120 alerts every day. One full time fraud prevention analyst should be able to handle the volume.   Within a week, $55K  of fraud attempts have been denied exclusively due to these new rules.  Two very experienced analysts enthusiastically told me that they like the rules.

These rules are designed to target the fraudulent transactions  at historically risky retailers, from possibly compromised cards,  with high transaction amount against card balance, etc.

There rules are completely transparent and are standard database SQL statements.

Implementing new fraud solution into the production system.

June 8th, 2010

We are working to implement our new bank card fraud solution into the production system. The initial results are very positive. As one of the analysts who has worked with the new alerts put it, “this rule can catch so many frauds.”.

Analyze billions of data records

March 22nd, 2010

I am using MapReduce and Hive (on Amazon EC2) to analyze large data sets.

Early Fraud Detection System

March 22nd, 2010

Traditional fraud prevention methods try to detect fraud when it happens. By exploring the unusually behavior patterns long before when fraud occurs, we are able to proactively prevent fraud with minimum impact to good customers.

SAS vs. Oracle SQL for data preparation?

March 5th, 2010

As we know, in a data analysis project we spend most of time preparing the data. I have found that using Oracle SQL for data preparation is handy. For example, to calculate the moving average for each patient, it takes more than 15 lines of SAS statements. When using Oracle SQL to do the same thing, it is simply a call of avg function, “avg(num) over(partition by patient order by month rows between 4 preceding and current row)”. Please see the scripts below. Could you share you experience in this area?

SAS scripts: Calculating moving average
proc sort data=ds1;
by patient;

%let n = 4;

data ds2;
set ds1;
by patient;
retain num_sum 0;
if first.patient then do;
if count gt &n then num_sum=sum(num_sum,num,-last&n);
else num_sum=sum(num_sum,num);
if count ge &n then mov_aver=num_sum/&n;
else mov_aver=.;

Oracle SQL: Calculating moving average

create table ds2 as select a.*, avg(num) over(partition by patient order by month rows between 4 preceding and current row) mov_aver from ds1 a;

We provide advanced Oracle SQL training for SAS programmers. For details, please contact me at jzhou@businessdataminers.com. We believe Oracle SQL skill could really make the data work more productive and manageable.