Chapter 5: Sweet Spots and Danger Zones

The ominous examples from Chapters 2 and 3 might lead one to believe that almost all organizations fail most of the time when it comes to generating and then acting upon business hypotheses. Actually, most organizations actually do a very good job with business hypotheses, and have for many years…in certain areas of their respective businesses or governmental agencies. Even predating modern analytics and big data, we can document numerous successes. Studying business hypothesis success stories presents us with patterns of where we’ve been successful, along with a framework for how to extend those success patterns into danger zones elsewhere in the enterprise.

Copyright © 2019 Alan R. Simon. All Rights Reserved.

Introduction

           Many of us have had the frustrating experience of attempting to make a purchase using a debit card or credit card, and having that transaction temporarily interrupted by the merchant due to the card issuer questioning the purchase. Usually, we become the ones responsible for somehow trying to validate that transaction in the eyes of the card issuer. The transaction might be initially declined, and it’s up to us to get things straightened out so the purchase can be completed.

           My most recent experience along these lines was a couple of years ago when I attempted to purchase a couple of moderately expensive prints from an upscale Scottsdale, Arizona art gallery as a Valentine’s Day gift. The transaction did not go through; apparently the fraud detection algorithms at the bank that issued my debit card decided that I wasn’t exactly the art buying type, and that there was more than a small chance that this attempted purchase was fraudulent.

           I immediately called the bank’s customer service phone number and after about twenty minutes (ten minutes of which was waiting time on hold), I was able to convince the bank that yes, indeed, this was a legitimate purchase. I did so by a) confirming the store name, location, and total purchase amount, and then also b) proving my identity by confirming the details of a sequence of previous transactions on record for my account.

           In this case it turned out that my bank had issued a “false alarm” about a suspected fraudulent transaction that, in fact, was a legitimate one. In another situation a couple of years earlier, though, I was called by a customer service representative for one of my credit cards who wanted to verify the legitimacy of an online transaction using my card number that their algorithms determined to be suspicious. In this earlier case, the online transaction was indeed fraudulent. It wasn’t mine, and they proceeded to immediately cancel my credit card number and let me know that they would send me a new card.

           Have you ever stopped to consider what goes on behind the scenes with consumer banking fraud detection and management? The sequence goes something like this:

• A transaction is flagged by the fraud detection algorithms as possibly being fraudulent…with the emphasis on the word “possibly” since at this stage, there is usually no way to determine with absolute certainty that a given transaction is or isn’t fraudulent. Or, stated another way: the bank or credit card issuer forms a hypothesis that a transaction is fraudulent.
• The attempted transaction is declined…essentially, the bank or credit card provider takes some initial actions to “prevent damage” (e.g., financial loss) while proceeding with a predefined workflow to either prove or disprove the hypothesis that the transaction is fraudulent. This initial denial of the transaction doesn’t mean that a subsequent replacement transaction won’t be approved, if the bank can verify that it actually wasn’t fraudulent; but for now, the attempted purchase cannot be completed because it’s been flagged.
• Usually, one more initial step will be immediately undertaken: temporarily freezing the account and/or the specific card number associated with the questionable transaction. Until the matter is cleared up, no transactions at all will be permitted on that account…or at least using that particular card, in the case of a debit card and the underlying checking account where written checks may still be processed.
• How does the bank or card provider prove or disprove their hypothesis? If the consumer calls in to inquire why an attempted transaction was denied, they’ll ask a series of questions that might indeed end up establishing the legitimacy of that suspect transaction. Or perhaps after a certain amount of time has passed, the bank or card company will contact the customer by to inform him or her of the rejected transaction, and proceed with the aforementioned series of questions. Alternatively, the bank or card company may send the customer a text or email and leave it to the customer to make contact.
• Regardless of how the communication flow occurs and through which channel(s), the workflow will drive towards the same outcome: definitively either a) proving the hypothesis that the transaction was fraudulent, or b) disproving that hypothesis and, instead, confirming that the attempted purchase was, in fact, a legitimate one.
• The workflow doesn’t stop, and in fact branches at this point. Specifically:
• >>>> If the hypothesis has been proven – i.e., if it is definitively determined that the attempted purchase was fraudulent – then typically the card number will be canceled and a new card will be issued to the customer. The account may remain frozen in place until the new card has been received by the customer and activated. Perhaps the fraud detection algorithms and models themselves are “enriched” as a result of having affirmatively detected and intercepted a fraudulent transaction.
• >>>> Alternatively, if the hypothesis has been disproven – i.e., it turns out that the transaction was a legitimate one after all – then the account itself and the card will be unfrozen, leaving the customer free to once again use the card. Very possibly, the profile for the customer that feeds into the fraud detection algorithms will be updated to reflect the “false positive” that was subsequently disproven. In the case of my temporarily interrupted Valentine’s Day art purchase, my bank likely updated my profile in a manner that if I were to subsequently attempt another art purchase in Scottsdale, or a similar “upscale” purchase, the new transaction wouldn’t be flagged as out of the ordinary.

           Credit and debit card fraud detection is a longstanding success story with regards to the formulation and processing of business hypotheses all the way to decisions and then actions based on those decisions. Certainly, the advent of big data and modern analytics has enriched our models to allow us to refine and improve these algorithms and our success rates at detecting consumer banking fraud. But the operational usage of analytics that begin with the formulation of a business hypothesis predate big data and modern analytics, and have served us well for a long, long time.

           Let’s look at another business hypothesis success story (thought you may not have viewed it in this context): computer and network security. Consider the following workflow:

• Your organization’s security software detects a particular pattern of activity, or something else in the data, that indicates a possible security threat.
• In response to this hypothesis some preliminary steps are taken, such as cordoning off a particular set of network and computing resources until this possible threat can be investigated further.
• Between the security software and also the efforts of your IT security personnel, a concerted effort begins to definitively determine if the security threat is genuine. Or, stated another way: you set out to either definitively prove or disprove the generated hypothesis that your networks and computers are being compromised.
• If you determine that the security threat is genuine, you will take additional steps. Perhaps you’ll lock down a larger segment of your computing and network resources. You’ll proceed to try to neutralize the security problem, according to what sort of threat (e.g., specific malware) has been identified.
• If, however, you determine that there isn’t an actual security threat – i.e., the alert was a false alarm – then, in effect, you’ve disproven the hypothesis. You will then release any locked down computing and network resources, and very likely conduct further investigation into why the false alarm was triggered in the first place.

           Notice the conceptual similarity between the workflow for credit/debit card fraud detection compared with the workflow for computer and network security. We’re looking at two very different domains. Yet beyond the specifics associated with each of these areas, we can lay the sequencing of each side by side and see more or less the same progression from data feeding into analytics that then forms a hypothesis, and then on through decisions and then on to actions…essentially, the baseline analytics workflow that we discussed in Chapter 1.

           So despite ominous, far-reaching, and damaging business hypothesis failures such as we saw in Chapter 2 with 9/11 and Chapter 3 with the General Motors recall, we also can point to business hypothesis success stories…plenty of them!

           What, then, separates our success stories from our failures; our “sweet spots” from our danger zones?

Characteristics of Business Hypothesis Success

           Every business hypothesis can be defined by three dominant characteristics, as represented in Figure 5.1:

1. The “flavor” of analytics used to generate the hypothesis…specifically predictive analytics, in which (by definition) we’re trying to predict what is likely to happen, versus exploratory analytics in which our primary objective is to feed mountains of data through our sophisticated analytics to discover, in a rather open-ended manner, what might be “interesting and important.” (We will discuss the analytics continuum, including both predictive and exploratory analytics, in Chapter 8.)
2. Whether we are working in a closely confined realm – e.g., within a single department, or perhaps a single business function – versus a much broader landscape across a sizable segment of the enterprise…or perhaps even spanning multiple enterprises.
3. Whether we are explicitly anticipating some specific alert or notification, or if the specifics of a business hypothesis that is generated might be totally unanticipated.

Figure 5.1 – Dominant Characteristics of a Business Hypothesis

           Now consider the two success stories from the beginning of this chapter. With credit/debit card fraud detection, we have a scenario where:

• We are focused primarily on predictive analytics: i.e., “predict whether or not a given customer transaction is likely to be a fraudulent one.”
• We are operating within a relatively confined segment of the overall enterprise of a bank or a credit card issuer: specifically, credit or debit card usage and detection of possible transaction fraud. We aren’t concerned with mortgage banking or wealth management services, or other service lines across the bank. In fact, even within credit and debit card usage we focus solely on fraud detection rather than credit risk, cross-marketing, or other consumer banking card functions.
• We are specifically on the lookout for patterns that indicate likely debit or credit card fraud. In fact, you could even say that we are anticipating alerts of possibly fraudulent transactions.

           As for our network and computer security example:

• We specifically focus our efforts on the security realm, rather than overall bandwidth and data throughput, server capacity management, and other systems/networking-related functions.
• We focus on predicting some attempted security breach, ideally as early as possible.
• We are on guard against these attempted security breaches, and anticipate that they will occur.

           Figure 5.2 illustrates the convergence of the “low end” of each of the three axes associated with our defining characteristics…essentially, our sweet spot for where we have our greatest successes with business hypotheses.

Figure 5.2 – The” Sweet Spot” of Business Hypothesis Success

           The further we move out on each of the three axes, the more uncertainty we introduce into how successful we will – or will not – be with business hypotheses (Figure 5.3). The broader the scope of the data and the functionality; the more exploratory “tell me something interesting and important” analytics we introduce into our models and algorithms; and the less anticipated that the specifics of a given discovery might be, then the greater the chance that we may wind up generating business hypotheses that do not end up successfully following through to decisions and then actions.

Figure 5.3 – Complicating the Business Hypothesis Picture

           Now consider the real-life failures described in Chapters 2 and 3: 9/11 and the General Motors recall. With 9/11:

• We were dealing with data, personnel, and work processes from multiple intelligence agencies that often did not work cooperatively or share data;
• Even though in a general sense we were on the lookout for possible terrorist activity, we weren’t actively anticipating an imminent attack, nor one specifically involving hijacked commercial airplanes; and
• The category of analytics that might have ingested large amounts of data from many different sources, in many different forms would have been more along the lines of “tell me something interesting and important from all this data” rather than the models that we typically build for predictive analytics.

           Likewise, with General Motors:

• They were dealing with work processes, personnel, and data from across multiple General Motors car brands as well as outside the GM enterprise (e.g., Delphi, the service departments at independently owned GM car dealers, third-party auto service shops, etc.);
• While product defects are – or at least should be – on the radar of every automobile manufacturer, a defect of this breadth and severity was apparently not anticipated; and
• As with 9/11, the models that might have alerted GM to this severe product defect are more along the lines of “tell me something interesting and important from all this data” rather than specific predictive analytics.

           As illustrated in Figure 5.4, 9/11 and the General Motors recall problem are indicative of the outermost sets of values along each of our three axes, and represent the danger zone for business hypotheses.

Figure 5.4 – The Business Hypothesis Danger Zone

What Does it All Mean?

           Business hypotheses, and the imperative to immutably carry them through to decisions and then actions, are a “cold, hard fact” in our companies, governmental agencies, and not-for-profit organizations.

           Wordplay aside re: the linkage between hypotheses and facts, the message is clear to us:

• Within our “sweet spot” where anticipated and constrained business hypotheses are generated as a result of predictive analytics, we often do a pretty good job carrying those hypotheses through to decisions and actions.
• Therefore, we need to carry our record of success beyond the “sweet spot” out into the danger zone, where far greater unpredictability and variability hallmarks the landscape.

        We do not have the luxury of focusing only on hypotheses that come our way inside of our comfort zone. As evidenced by the 9/11 and General Motors examples from Chapters 2 and 3, mission-critical decisions will need to be made and subsequent actions will need to be taken as a result of hypotheses with characteristics that place them into the danger zone.

           Our mission is to understand the technology, workflow, and human factors associated with our successes and extrapolate those characteristics and patterns out into the danger zone, where successes are much more sporadic. Chapter 7 introduces this solution set as a lead-in to Parts II, III, and IV of this book.

           First, though, we need to revisit “Simon’s Corollary” to better understand the challenges that need to be overcome by our solution set.

________________________________

Alan Simon is the Managing Principal of Thinking Helmet, Inc., a boutique management and technology strategy consultancy specializing in analytical business process management, business intelligence/analytics, and enterprise-scale data management.

Alan is the author or co-author of 31 business and technology books, dating back to 1985. He is also the author of five LinkedIn Learning/Lynda.com courses, the most recent being EDGE ANALYTICS: IoT AND DATA SCIENCE.