Like many markets in technology, the fraud detection and prevention category is a crowded one. With different types of solutions approaching the fraud problem space from different angles, it’s worth asking the question: What problem or problems are we actually trying to solve with this class of solutions? To my knowledge, enterprises are most often interested in reducing fraud losses. This allows them to improve profit margins by reducing costs due to fraud losses and improving their bottom lines.
Seems sensible and straightforward, right? Indeed it is, which is why you can understand my surprise and confusion at how many enterprises aren’t focused on reducing fraud losses. Or rather, their intent is to focus on reducing fraud losses, but their actions won’t bring that about. What do I mean by that? Allow me to elaborate.
There are still a large number of enterprises that attempt to tackle the fraud problem through what are now legacy approaches. For example, some enterprises may try to detect fraud by looking for users that are accessing their site while infected with malicious code. Or, as another example, some enterprises may look for users being referred from known phishing sites. While these may seem like legitimate techniques, they don’t actually reduce fraud losses. There are many reasons why this is the case. Here are just a few of them:
● Whack-a-mole: Running around chasing malicious code infections and phishing sites is a bit like playing whack-a-mole. The minute you clobber one, another one pops up. In other words, although you spend a lot of time, energy, and resources fighting these issues, you don’t actually mitigate much, if any, risk.
● Signature-based detection is unreliable: Many approaches to detecting malicious code involve a signature-based approach. The data show that this approach is ineffective and unreliable. A majority of malicious code still goes undetected. Any malicious code that is detected often comes at the cost of a large number of false positives. To frame it another way, signature-based detection approaches don’t work particularly well and they don’t mitigate a lot of risk. That means that if your fraud strategy relies on detecting malicious code infections and phishing sites, it’s not going to be a winner.
● Compromised credentials do not equal fraud: Even if an enterprise is able to detect malicious code infections and phishing sites, that in and of itself won’t help them uncover fraud. Why? Say an enterprise has a list of compromised user accounts. What action will they take with that list? A business is not likely to block its own customers – that certainly isn’t good for business and it isn’t good PR. So what options does that leave the business with? That is a great question and one that will be the subject of the remainder of this piece.
The clever reader might now ask – can’t I look for fraudulent activity on the accounts of compromised users? Indeed you can, and that is necessary but not sufficient for detecting and preventing fraud. Why? Because fraud happens whether or not we’re aware that specific credentials have been compromised. Thus, if we key our entire workflow off of compromised accounts that we’re aware of, we will miss all of the fraud happening due to compromised accounts or any other reasons that we’re not aware of.
Nonetheless, the idea of looking for fraudulent activity by looking at transactions at each and every step of the user journey is headed in the right direction. It is a far more effective way of detecting and preventing fraud than relying solely on the detection of malicious code infections and phishing sites at login – very early on in the user journey, a single point of failure, and not particularly actionable.
It is here that we come to the crux of the matter. If an enterprise understands that separating fraudulent transactions from legitimate ones is the best way to detect and prevent fraud, then why would that enterprise not shift its fraud strategy from signature-based to behavior-based? In other words, rather than focusing on infected and phished users, the enterprise needs to focus on strange, anomalous behaviors, unusual environmental factors, and transactions that do not appear to be legitimate and expected.
So what are the benefits of moving to behavior-based and transaction-based, rather than signature-based fraud detection? There are many of them, though here are a few examples:
● Less dependency: Fraud detection and prevention are no longer dependent on knowing which credentials have been compromised.
● Lower false positive rates: Fewer false positives means less noise. That means less precious human cycles consumed with dead-ends.
● Higher true positive rates: More true positives means detecting and preventing more fraud. That means fewer losses due to fraud and an improved bottom line.
● More actionable alerts: Knowing the nature of a transaction (e.g., legitimate, suspicious, fraudulent, etc.) allows an enterprise to take action on the transaction – to permit, deny, challenge, review, etc.
Playing whack-a-mole with malicious code infections, phishing sites, and compromised credentials won’t help an enterprise reduce losses due to fraud. Instead, enterprises should focus on detecting and preventing fraud by separating fraudulent transactions from legitimate ones. After all, if what we’re after is reduced fraud losses, it only makes sense that we look at the fraud problem space from a more sensible angle.
