Incorporating Behavioral Analytics into Exception-Based Reporting O R A C L E W H I T E P A P E R D E C E M B E R 2 0 1 4

Incorporating Behavioral Analytics into Exception-Based Reporting O R A C L E W H I T E P A P E R D E C E M B E R 2 0 1 4

Table of Contents Introduction 3 What are Behavioral Exceptions? 3 How Do Behavioral Exceptions Differ from Traditional Exceptions? 3 Examples of Behavioral Exceptions 4 Credit/Debit Card Net Negative 4 Line Void Analysis 5 Using Previous Incidents/Cases to Identify Telltale Sales 5 Impacts from Policy, Procedure and Internal Systematic Controls 5 Conclusion 6 2 INCORPORATING BEHAVIORAL ANALYTICS INTO EBR

Introduction Exception-based reporting administrators or users often hear the following from field team end users: Have the system tell me who s stealing or doing something wrong, and we will take care of it. What they really want is a report that tells them who, how, what and why, without having to think about it. As many retailers know, fraud can be disguised by training issues and vice versa. So how do you determine fraud versus training issues and take institutional or tribal knowledge and build meaningful reports for end users? Loss prevention/audit analysts can identify issues that need to be addressed, but the challenge of determining if a situation is a fraud issue or a training issue requires a deep understanding of the business and is often a manual process. Two individuals can display similar activity (count of transactions and total amounts), when only one of them is committing fraud. There are, however, indicators or red flags that make one individual stand out from the other. Many loss prevention/audit experts learn to identify these red flags over time and through experience become very perceptive about what to look for during their investigation/audit process. This process of evaluating and analyzing information is different for each professional, based on their experience and knowledge of procedures and system functionality. How does that knowledge get transferred into an exception-based reporting application to get the end result analysis with less manual effort? This paper defines behavioral exceptions including detailed examples and how to differentiate them from transactional exceptions. An approach to identifying telltale signs of fraud, as well as the business impact of strong policy, procedures and internal systematic controls are also discussed. What are Behavioral Exceptions? Behavioral exceptions take the knowledge of red flags from a macro level to a micro level, and allow the exception-based reporting system to instantly perform an analysis at a level of detail that would take an end user many hours to complete manually. By setting the system up to understand red flags and alert the user to the activity more quickly, the end user can reach the following goals:» Prevent further activity with faster response time» Use less effort to investigate» Reduce the number of false-positive exceptions How Do Behavioral Exceptions Differ from Traditional Exceptions? Exception-based reporting provides the ability to look for patterns or trends that can identify unusual activity that may assist in identifying operational/training issues, external/internal theft and other noncompliance issues. 3 INCORPORATING BEHAVIORAL ANALYTICS INTO EBR

Traditionally, this is done by looking at a combination of transaction, discount and tender types. This can be summarized as the count of or amount of the following:» Transaction Types - refunds, post voids, cancels/voids, no sales» Discount Types - price overrides, line/transactional discounts, coupons, promotions» Tender Types - cash, credit/debit, gift card/merchandise credit, check/travelers check, house charge The primary goals of exception-based reporting are to identify issues, address them, and prove steps to prevent them in the future and to minimize the loss a company incurs. The results are dependent on the support team s ability to act upon exceptions, and their effectiveness in using the information provided by performing additional research and gaining a deeper understanding of the data. The faster behavioral exceptions are identified, the less time there is for fraudulent activity to occur. Unfortunately, identifying patterns or trends typically takes time. In addition, according to the Cressey s Fraud Triangle, which is widely used in loss prevention and by organizations like the Association of Certified Fraud Examiners, committing fraud is influenced by three factors: opportunity, rationalization and the level of pressure/incentive. Beyond normal counts and amounts, what detailed behaviors constitute a true exception? Although these areas quickly identify highrisk activity, numerous factors can impact exceptions. Therefore, many exceptions are designed to reflect differences in:» Employee Status - tenure, position/role, full/part-time» Merchandise - department/class, type, cost point/value» Location - business volume, size, region, demographics, register Eventually, these exceptions will narrow down the behavior of what is actually occurring and help identify and evaluate the true exceptions. Answering questions such as What makes this activity truly an exception that needs further research? will help narrow down the details of what is occurring at the time of the transaction. Possibilities include:» Activity at line/item level - voids/deletes/clear or discounts/overrides» Receipt vs. non-receipt or older receipts/reprinted receipts» Scanned/swiped vs. manually keyed» Same/similar amount - comfort; systematic limits or policy and procedure thresholds» Same/similar time periods - lower coverage, increased opportunity» Other impacts - policy and procedure or system controls/capabilities Examples of Behavioral Exceptions Adding information about behaviors that are occurring makes it easier to determine the next steps and what is actually going on. The following two scenarios are examples of typical investigations that may still require further investigation, but adding information to the report simplifies what needs to be done next. Credit/Debit Card Net Negative This is essentially a summarization by the credit/debit card account (or unique identifier for the account) of the total balance that has been processed. If the net amount is in the negative, the possibility of fraud is higher. Adding a few key pieces of information helps identify issues sooner, including those that may not be truly in the negative. The end result is that the report becomes more effective, and it is more efficient to analyze and investigate. Fields to consider are:» Distinct Count of Stores - low store count indicates more than likely an internal issue where a higher store count may indicate an external issue» Distinct Count of Cashiers low cashier count typically indicates there may be internal involvement» Count of Employee Transactions linked to employee, does not require much investigation» Amount Returned may indicate an internal or external issue. What is a reasonable number of returns for one account?» Amount of Employee Returns if it is an employee account, why are there so many returns? 4 INCORPORATING BEHAVIORAL ANALYTICS INTO EBR

» Amount of Non-Employee Returns if it is an employee account, it is not typical to have non-employee activity. Why are there non-employee returns? Similar logic can be applied to merchandise credit and gift card activity. For example, if we were to see a scenario in which a merchandise credit is issued against a full-price return and is subsequently used in an employee purchase, this could be a clear indication of fraud. Line Void Analysis Analysis of line voids can be like finding a needle in a haystack. Each analyst needs to consider what a reasonable level of void lines should be based on how many items, transactions and types of merchandise were processed by the cashier or store. By identifying the transactions that have a higher potential for fraud, it is easier to determine who may be performing pass-offs or committing cash theft. Transactions with a higher number or dollar amount of line voids, when compared to the actual product being sold, are a good initial indicator. The transaction duration and the line sequence number of voided items for example deleting all items except for the last one would also be red flags. Using Previous Incidents/Cases to Identify Telltale Sales Taking existing incidents or cases and looking at the data through the application will help determine what type of pattern is occurring, and if there were any indicators that could have been used as red flags. Refund fraud is one of the easiest types to identify and has many red flags, including: same item, same amount, same day original receipts, same cashier from original receipt, items manually keyed, single item refunds, price adjusted refunds, even dollar amount, and no original receipt. Another indicator is the time of the transaction, such as before or after store hours and during non-peak or low coverage, such as during meal breaks or shift changes. Impacts from Policy, Procedure and Internal Systematic Controls There are numerous impacts to be considered through data analysis. Policies and procedures help lay out operational controls, but many times these policies are not followed. Being able to address and reduce the number of training or operational issues will help eliminate false positive exceptions. Systematic controls prevent certain transactions from occurring, reduce thresholds and require management team approval. These controls can change the method in which fraud may occur and may increase the number of exceptions. An exception-based reporting system needs to be a shared resource that all stakeholders can use to optimize the benefits of the program and maximize the ROI. Some of the ways that businesses can benefit are to expand who receives exceptions data to include various teams, based on type of exception, frequency or amount. In addition, there needs to be a framework for who will handle the exceptions, and how they will be managed, in order to reduce potential duplication of effort, and minimize impacts to potential investigations. 5 INCORPORATING BEHAVIORAL ANALYTICS INTO EBR

Conclusion By using prior observation and reverse engineering of previous cases, reports can be designed that quickly alert the user to activity that requires further scrutiny. This may sometimes be a training issue, such as an associate performing a line void instead of using the price lookup function to check the cost of an item. At other times an analysis will warrant a discussion with the employee. Businesses should always be aware that compliance, auditing, training and awareness programs will all impact what occurs and often shift fraud into other areas within the organization. It is critical to always be on the lookout for new behaviors that may identify high-risk activities. A partnership between loss prevention, sales audit, operations, marketing, and IT is crucial for an effective exception-based reporting program at any company. An understanding of the company s business, operations, best practices, and reasonable expectations will make the system and its users successful. For more information on Oracle s loss prevention solution for managing exception-based reporting, contact us at oneretailvoice_ww@oracle.com. Oracle Corporation, World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA Worldwide Inquiries Phone: +1.650.506.7000 Fax: +1.650.506.7200 C O N N E C T W I T H U S blogs.oracle.com/oracle facebook.com/oracle twitter.com/oracle oracle.com Copyright 2014, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 1214 Incorporating Behavioral Analytics into EBR December 2014