Showing posts with label predictive model deployment. Show all posts
Showing posts with label predictive model deployment. Show all posts

Friday, August 02, 2013

My Check Fraud Detection Model Reduces Fraud by 60%

A project manager from a bank just told me that the model developed by me has resulted in 60% reduction in fraud loss. He said "everyone was surprised at how effective it was." It was a model that I developed two years ago for a top 15 bank.(Of course, I was not surprised at all since the model was tested on holdout data sets and showed similar performance).

The model was built and deployed on Oracle databases. The main reason for the success of the model was that I spent huge amount of effort building model variables that captures the fraud patterns. Luckily, I used Oracle analytic functions to build those variables easily. (Please see my posts "How to build predictive models that win competitions" and "Recency, Frequency, Monetary (RFM) Analysis: Part 1"

Another important advantage of using an uniform platform, i.e., Oracle databases, is that the deployment is easy. I simply deployed the model as a set of SQL query. See my posts "Build Predictive Models Using PL/SQL" and "Logistic Regression Model Implemented in SQL"

Monday, August 27, 2012

Predictive model scoring in Oracle


As described in an earlier post, "Build Predictive Models Using PL/SQL", we can build models within Oracle using function 
DBMS_DATA_MINING.CREATE_MODEL. The models are called mining objects.

The ultimate purpose of building a predictive mode is to apply it to new data. This can be done using SQL function prediction_probability(). 
We call this function in our SQL scripts. It will return the probability of being fraud, delinquency, clicking an online ads, or whatever the model is predicting.

select ACCOUNT_NUM, Transaction_ID, prediction_probability(fraud_model,  1 using *) score from tbl_transaction_data;

This is probably the most efficient way to deploy a model into production. (Model deployment is traditionally a major headache.) Again, data never leave the database and no standalone analytics server is needed.