Many companies are looking at fraud detection using data analysis because, whenever there’s a fraud case in the news, it seems that it was ongoing for more than a year before anyone caught it. There are hundreds of fraud schemes out there, and more are being developed all the time. We can’t come up with a push-button app that will automatically detect fraud, but there are a few warnings in the data. We, as auditors and technology professionals, can try to spot the red flags.
There’s not enough space in this blog post for all the details I will be presenting on this topic at North America CACS 2017, but I can give you a taste of what data analytics can and can’t do to detect fraud. As I mentioned, there isn’t an app that can detect fraud. It seems that fraud often starts as an honest mistake, and if no one notices, then a fraudster “accidentally” does it again.
It would be nice if the internal controls were set up to prevent these mistakes. In many cases, they are. But, far too often, there’s a manual element in controls, and human error comes into play. We have logs, for example, of logins, database changes, firewalls, Internet sites, etc., – gigabytes of log data that often go unmonitored until an issue is raised somewhere else. We have complex enterprise applications that have dozens of modules, large IT support and hundreds of users. No one person is capable of knowing all the interfaces, tables, function calls and transactions that are included in enterprise resource planning (ERP), such as Oracle Financials or SAP. And, while the data is there, it’s difficult to find the fraud indicators amidst the huge number of daily transactions.
So, what can we do in the face of all this data? How do we find the needle in the haystack? We have to take it one step at a time. We can try using Benford’s Law or the relative size factor test to find outliers, but these are exploratory analytics – they might point out an anomaly, but these will often turn out to be normal transactions. We want to find something a bit more specific to the scheme if we’re really going to try to find fraud. This is not the easiest thing to do, but it can be the most fun. It is for me, anyway!
We need to focus our attention on a specific fraud scheme. Think about the process we want to check, and then think like a fraudster. Brainstorm with your peers and a subject matter expert or two, and consider how the system could be misused or gamed to commit fraud. Think outside of the box. Once you’ve collected a number of ideas, assess which ones might be most likely (or most costly, most undetectable, etc.), and start thinking about what data might indicate that such a scheme is underway. Then, design a data analytics test to explore that possibility. Duplicate invoices? Use a fuzzy match on invoice numbers, vendors and costs. Fraudulent travel expenses? Compare travel dates to the expense dates, or look to see if there are taxi receipts along with car rental.
I’ll be going through this in more detail, and providing more concrete examples, at NA CACS in May. I hope to see you in Las Vegas!
Editor’s note: Richard Fowler will present on “Fraud Detection Using Data Analysis” at North America CACS 2017, which will take place 1-3 May in Las Vegas, Nevada, USA.