I'm doing some research into fraud detection for academic purposes. I' d like to know specifically about techniques for feature selection\engeneering from a transactional dataset. In more details, given a dataset of transactions (credit card for example), what kind of features are selected to be used on the model and how are they engineered?

All the papers I've come across focus on the model itself (SVM, NN, ...) not really touching on this subject.

Also, if anyone knows of public datasets that are not anonymized - that would also help.

Btw I've already been through this answer Thanks


2 Answers 2


I'll argue that fraud detection will have very few positive cases and a big number of negative cases in any reasonably real-like dataset. In other words, you will be solving an anomaly detection problem, where the fraud is the anomaly and normal (non-fraud) cases are the remaining samples.

Answering the question itself: In anomaly detection there are two important parts to any detection system:

  1. The capability to add new features easily.
  2. The capability to explain which features caused a point to be considered an anomaly (fraud).

This leads to two things that we can say about fraud detection: (1) you cannot perform generic feature selection (e.g. feature hashing) or dimensionality reduction, since that will destroy the explainability of your system. And (2) you need a model that will cope with extra (likely correlated) features.

Personal Experience

From my experience trying to build an anomaly detection system for financial data (not strictly fraud detection but pretty close) I will argue that you want to start with as many features as you can. In my case we jut took the entire record the payment system we looked at had in the log (in a SQL table) for the transaction and added to it what we could take from the application logs as well.

We ended with something including: several global locations for the transaction origin and issuer (city, country); all data on the card chip sent both ways, ciphers used and ciphers negotiated, timestamps in both timezones (origin and issuer), time to process the transaction, and a couple of other more business specific parts of the log (e.g. visa or mastercard).

A lot of the above was heavily correlated (e.g. date with time of transaction, time of the day of transaction), so we went over each column, estimated the variance (number of distinct values in the column divided by total number of data points) and:

  1. If the variance was too low (only 1, 2 or 3 distinct values) we did throw away the column.
  2. If the variance was too high (>0.8 using the estimate above) we did throw away the column.
  3. We correlated the columns and within groups of columns (high correlation) we choose the one column with variance (estimated as above) closer to 0.5 .

Based on the variance estimate we also decided how to engineer the features: For timestamps we took mostly the hours of the day (i.e. without the date part) since that was the column with the most reasonable variance estimate. For text features with a very limited scope (e.g. ciphers) we did one-hot-encoding. For long strings with a lot of variance we found out that the length of the strings is quite a good indicator. And so on, column by column.

We then used an isolation forest to find the anomalies. Every time we need to add more features because someone (a human reporting a problem) find another good indicator, we correlate the new indicator column with the columns we have and decide whether we can improve the detection engine by adding the feature or by tweaking sample weights.

In summary (TL;DR)

You are facing an anomaly detection problem. You want to place in as many features as you can, and then you need some way of of estimating correlation and variance to evaluate the feature columns in a raw state (e.g. no dimensionality reduction). Then select the columns (features) looking at the estimates.


Feature selection and engineering are different concepts. There are many automated approaches to selection (eg, regularization) that are easy to look into. The meat here is in feature engineering, and it requires creativity and trial-and-error. There aren’t hard and fast rules. Besides engineering features you already have (eg, some transformation, imputation), the creative part comes in adding new features based on information you might be able to pull out or add from external sources. For fraud detection, think about things like time of day, industry segment, originating account holder size, frequency of transactions, historical record, variability of transactions, etc.
In other words, you must think through the problem from multiple angles and identify characteristics that might be quantified despite not being readily available. A good example of this is solving the ‘titanic’ dataset. Kagglers have achieved impressive accuracy through feature engineering.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.