We’ve got lots of data in Loss Prevention (LP): months of video stored somewhere in our infrastructure and multiple systems that house financial data. For years, we’ve described the need for a data pipeline to consolidate all that data into one place to better understand our business. The data pipeline implementation takes the raw data in an operation and stores it in a data lake. From the data lake, one can join all this disparate data and video together in multiple ways to derive more insight from these assets.

Let’s say an LP staff member finds a new exception scenario that is causing your organization to lose money. Cashiers are creating point of sale transactions when the video surveillance shows no customer is present. You can take this new exception scenario and aggregate the data into a polished data mart—a place storing only the subset of data necessary for LP end users to effectively understand the exception. This process makes the charts appear faster on the screen when this new insight is shared with colleagues.

“We found a great new LP exception scenario in our data! So, now what?”

Depending on the Business Intelligence (BI) platform bought or built, you can either create a clean looking dashboard with the same tool with which the data is modeled; or you can buy/build an additional tool to present the data to stakeholders:

• They need to access it:  VPN? Web application? What credentials do they use?
• You must ensure they only see data they are entitled to see: Are they allowed to see data from that division or that one or…?
• They must understand what they’re looking at: What type of chart? What’s the drill through sequence? What action should they take after assimilating the data?

What’s the point of providing this new insight to everyone?

That question just above is the kicker, and it is easy to forget. How to make this new LP Exception Insight worth all this work? How many BI tools include case management? If your team needs to act on this data, they should be able to do it without going to a separate application. So, you can buy/build an end user application with the following workflow:

1. Exception takes place
2. Data is aggregated and rolled-up through LP data pipeline
3. The appropriate end user gets an alert to review the exception
4. The LP end user reviews the exception and takes the appropriate action within the application
5. They’re catching insider thieves in droves and increasing the bottom line by reducing shrinkage

Good news, right? But looking closer, you realize only 20 percent of potential end users have adopted the application. With greater adoption, you could increase your savings by a factor of five! 

You promised me AI in this article—where is it?

Alright, here we go: You’ve identified the A players in your LP operation who are viewing their videos, classifying them as fraud and getting their tasks done to fix the problems. You wish you could clone them and put them in your under-performing locations. Now for the possibly far-fetched AI claim:

Not only can applying AI to this workflow clone your A players, it can also make your A players better! 

If you’ll indulge me, I’ll explain. First, if your question is: Should the video classification data from A players be sent back through the LP data pipeline into the data lake? The answer is: Absolutely! 

Now that the video classifications of fraudulent actions are back in your data lake, you can train a machine learning model based on the data your A players have classified as fraud. The goal of the AI model is to find trends in the exception transactions where your A players found fraud, then proactively identify transactions with similar trends as potential fraud. Once the model is trained, you can test the machine learning model against exception transactions that have not yet been classified. You know, the ones from the underperforming store locations where nobody looks at their tasks and problems are going unsolved.

From there, you can create a feedback loop with your A players to see if they agree with the output of the fraud detection machine learning model. This is an iterative process, and there are a bunch of knobs you can turn to fine tune a machine learning model. I won’t sugar coat it: this can be hard work. There isn’t an “Easy Button,” however; the benefits can be well worth the investment.

Only exceptions that are thoroughly understood work for manual classification—you have to know what to look for. Remember all the work you did in your data lake to flag this exception in the first place? Fraudulent behaviors may be complex and change over time. The efforts of your best classification talent can be invested into a machine learning model without overworking them. The machine learning model can find additional trends in, for example, fraudulent receipt data that even the best humans couldn’t find. This is how AI can take the efforts of your best talent and make them better. You’re not replacing them, because without their hard work there would be nothing with which to train the machine learning model. Our humans and machines are working in harmony.

Beyond BI – AI and action

There you have it. It is more than just good data and beautiful charts, but the results aren’t mythically far-fetched either. The data analysis best practices from years past are not irrelevant; as an industry, we’re simply able to build on them to keep getting better at reducing fraud and shrinkage within operations. How many vendors does it take to pull this off? What skillsets do those vendors need? To be continued…