I have been in fraud detection and mitigation for the last decade. The term fraud is used in many ways and sometimes used interchangeably with Abuse. To disambiguate the 2, my definition of fraud is when a bad actor commits an action that impacts a third party in addition to the merchant. For example, a bad actor get holds of a stolen credit card and uses that to make a purchase in an online store. In this case, the impacted parties involved are the bad actor, the merchant and the person whose credit card was stolen. Abuse is an action committed by a bad actor that only impacts the merchant– an example is when a customer tries to use a promo code multiple times by creating fake accounts and uses the promo code multiple for their personal benefit.
Abuse tactics and mitigation is it’s own deep topic and I will cover here. This post is focused on Fraud.
I have worked in fraud detection that covers payment fraud, account fraud and supplier/seller fraud. The strategies and tactics are very similar for each of them, the differences are in the signals used to detect, the systemic latency requirements and the time to make a decision on the transaction.
Before I discuss the set of capabilities required for effective fraud detection and mitigation, I am going lay out some framework for how to think about managing Fraud.
- Fraud loss will never be zero, the only way to make it zero is to shutdown the business
- Each business has to determine their thresholds for false negatives (take a loss) and false positives (lose a sale) and need good mechanisms to monitor these metrics
- It is difficult to detect and mitigate one-off fraud, the focus has to be on preventing large scale systemic attempts or repeat fraud
- Build systemic capabilities that allows your teams to move quickly to an emerging fraud trend
At the highest level, an API to detect fraud has to be exposed to the clients to determine the risk of a transaction. The API typically provides a recommendation of ‘ACCEPT’, ‘DENY’ or ‘REVIEW’. The first 2 recommendations are obvious, the reaction of the client to ‘REVIEW will vary based on the business process. An eCommerce business that ships physical product can use that recommendation to manually review those transactions for fraud and make the final decision before shipping, while a digital product store can use that recommendation to delay fulfillment of the digital product until the manual review and decisions are completed. In an account takeover scenario, the ‘REVIEW’ recommendation can be used to trigger MFA.
For the API to work well and for the team to react quickly to emerging trends, a foundational set of capabilities are required – below are some
- System to understand the business process and determine the set of data signals and rules to execute
- System to gather additional data signals required for the recommendation
- System to aggregate key anchor points in a specified time interval and for computation
- Rule engine to write and execute rules, the team should be able to write rules on any available data signal and computed attributes
- Machine learning models (optional) that return the probability of risk
- Tool set to manually review transactions and make the final decision or pull up random transactions and override the system decision
Building the above discrete set of services/systems allows the developers to make changes quickly in one part of the system quickly without breaking/requiring changes in others (multiple blog posts required to explain the details) and is key to reacting rapidly to emerging trends that require new data signals or computation of a new attribute. Making rule/aggregation/computation changes should be a self service administrative task