Like any other field, there are conventions and (few) blog posts about fraud prevention specifically, and behavior management generally (be that abuse, spam or anything else). There is, though, an air of secrecy around these topics that always leaves the discussion at a very high level: no numbers around KPIs, no discussion of best practices and little sharing of information other than explicit blacklist data. This is a situation that has to change if risk management online is to become a real practice, and with the growing need for risk experts it is a must.

Secrecy in fraud prevention can be driven by multiple reasons, but mostly for competitive advantage – whether the company thinks that telling too much about its fraud prevention will tip off fraudsters and competitors, or risk staff feels that not sharing what they know gives them career advantage over others. Both considerations are true to some extent, but not to the extent to which they currently justify secrecy.

The truth about fraud prevention is simple: there is a finite set of generic tools and indicators that you can deploy. The key to differentiating in risk is not the run-of-the-mill 80% but rather in the 20%, and those are the ones that should be kept secret – interestingly enough, usually those are the ones hardest to steal and transfer anyway.

What’s in the 80% and what’s in the 20%? Let’s look at a few examples.

Tools? When I tell you that every risk team must utilize linking, velocity, rules, modeling and manual review tools (the “Basic toolbox”), that’s the 80%. Even if we discuss particulars of implementation such as the right type of edit distance for fuzzy matching an address, this is still far from the 20%. Are you really giving away competitive advantage? The type of customer and data your colleague is working with may not be the same. Shopping cart design may even impact the types of typos good customers do, which then impacts normalization and matching.

Procedures and Analytics? The way we develop and implement rules in Klarna may give us some competitive advantage, but that is not because of our procedures or the fact that we use control groups. It’s only in the mixture of hiring, training, day to day mix of detection/analysis/action that the competitive advantage is attained and maintained. Risk and fraud prevention are inherently operational practices – user behavior is constantly changing, if only for the changes in the product or macro-economic trends. In consulting assignments I sometimes found myself explaining essence and implementation to a very detailed level only to see it being missed or misinterpreted in execution.

These are two examples, but there are more. Of course some things must be confidential. Your training plan, your hiring methods, and the code for the variables used in your models are all good examples. Consider this, though: if your success depends on fraudsters not knowing that emails from yahoo.com are always suspected while emails from intel.com never are, you’re in trouble no matter WHAT is in your “secret sauce”.

Secrecy is important, but the current fear of collaboration is hurting more than helping. I’m not suggesting open sources, but I am suggesting that risk management should be more similar to standard software development. This will allow us to focus on the hard problems of implementation, operation and real innovation.