Patrick Taylor is the chief executive officer of Oversight Systems, a Continuous Transaction Analysis platform for big data that helps businesses make smarter decisions. In this interview Patrick talks about how Oversight Systems’ platform is used to detect fraud and internal security flaws. Furthermore, he describes the platform’s capability of resolving problems and finding new opportunities for businesses.
Sramana Mitra: Patrick, let’s start with some background about Oversight Systems. What do you do? What kind of target customers are you working with?
Patrick Taylor: There was a group of us in another company called Internet Security Systems. At Internet Security Systems, we had pioneered a concept called intrusion detection software. That is software that looks at network traffic to identify hackers – this is sort of an intruder alarm for hackers. The observation we made was that as much money people spend to stop hackers, they actually lose more to internal fraud. So, the concept was, Why don’t we build a product that starts looking for internal fraud? Those are things that happen in accounts payable, travel expenses, or even on the sales side sometimes.
Another observation we made at this company called ISS: We had missed a market opportunity that was closely related to intrusion detection. That market opportunity was something called security information management. This is an important concept because these intrusion detection systems produce a lot of alerts, but somebody needs to sort through those and weed out the false positives or see if there was actually something, and then look at it and investigate the process and fix the security hole. We said, “This problem that we are after is going to have the same characteristics.” By that I mean that we are going to find stuff, but somebody has to do something with it once we found it. We built in a workflow and [page] management capability to go along with this analytic capability. When we went out and did our first deployments, we were working in a shared service center in Las Vegas – a place where a company puts all their accounts payable through one group, and this group had to operate outside Las Vegas. We did some runs, and we came back and said, “Hey, is this fraud?” The guy we were working with said, “No, this is not fraud.” We went through this two or three cycles over the course of a week. We were adjusting analytics, etc. But we were just not finding fraud. Frankly, our guys are pretty suggestive. Fortunately, the customer came to us and said, “Well, this wasn’t fraud, but at least you found an error we made here and we are overpaying this bill there. When I look at this, you can identify it as a bomb, do some more training or put them on a 30-day plan.”
We discovered that in the process of looking for fraud, you find a lot more other interesting things – other potential anomalies. This is sort of how we got started. As it turned out, fraud was a useful design point. Had we had more foresight, we would have realized if we were in the process of dealing with big data analytics problems. Let me explain why design was a useful design point and why it fits into that. In the first place, in the case of fraud you are looking for very few events among many. In most business processes, there are only a handful of fraudulent transactions a day. Somebody is trying to cover that up – they are trying to conceal it, which drives you toward this idea of saying, “I need to look for a wide range of evidence. I need to look for lots of indicators.” There is a concept in artificial intelligence called evidentiary reasoning, which is the idea that “I have to look for lots of pieces of evidence and let those build up a conclusion for me.”
Another great part about fraud is the design point. If you are going to catch somebody committing fraud, what you want to try to look at is, why did they do it? Let’s say a business process runs through two or three different systems. But you want to pick up not only what has happened that day [from] the ERP system, but you may want to pick up shipping records from the application that they run on the loading dock. The more comprehensive you make it look, the harder you make it for somebody to cover their tracks. I can cover my tracks in a few places, but it is hard to cover them completely everywhere. We need you to say that we have [evidence from] a lot of data sources. The other thing is I can’t depend on having every data source I need every time to evaluate each transaction. I need to have some robustness in terms of dealing with incomplete and imperfect data. Yet all of these attributes ended up being useful in a lot of other problem domains. This is the story of the company’s evolution. We were fortunate to have a very good design for us to start out with.