False Lights: How Thin Customer Feedback Can Steer Executives Onto the Rocks

Thin customer feedback misleads executives when a single complaint, like someone wanting a bypass button for a security warning, gets compressed into a generic lesson about balancing security and convenience, losing the critical context that the bypass could be exploited by fraudsters through social engineering, weakening real protections.

There is an old maritime story about wreckers who placed false lights along dangerous coastlines. Sailors believed they were following a safe navigational signal, steered towards it, and ended up on the rocks instead. Historians dispute whether these stories happened in the way folklore describes them, but the metaphor still earns its place here, because the most dangerous signal is not always the absence of guidance. Sometimes it is guidance that looks entirely credible while pointing in exactly the wrong direction.

Large organisations create false lights more easily than most people realise, and they usually start from something completely real, such as a customer complaint, a social media post, an escalation, or a piece of qualitative feedback. That information gets compressed into a summary, the summary becomes a lesson, the lesson lands in an executive report, and eventually someone with very little time reads it as evidence that the organisation should change something. At every stage of that journey nuance disappears a little more, until an anecdote ends up carrying an authority it never earned, which is tolerable enough when the subject is the colour of a button and considerably more serious when the subject is fraud and cybersecurity controls.

1. The complaint

Imagine a customer complains publicly on social media that a banking app has flagged software on their phone as suspicious. They want to keep the software installed while continuing to bank, and their suggestion is straightforward, which is to give them a simple ignore button so they can bypass the warning.

Suppose someone from the bank contacts them directly, because false positives matter, and because if the bank is incorrectly blocking legitimate software that is worth understanding before the control gets defended any further. The customer’s response is revealing, though not because of anything specific to them personally. A security control flagging a device condition or a piece of software does not necessarily mean that application has been conclusively classified as malware, since it can just as easily mean an unsafe capability, an overlay behaviour, an accessibility permission, a remote control tool, or another risk signal has been detected. The customer’s confidence that the software is legitimate rests on their own knowledge of where it came from, rather than on any evidence about why the security control classified its behaviour as suspicious, and those are two different kinds of confidence, where only one of them is actually evidence, yet they repeat the request for an ignore button regardless.

The bank’s answer has to be that it cannot simply build that, because one defining feature of modern fraud is that the victim is socially engineered rather than technically defeated. An attacker often does not need to beat every technical control directly, since they only need to persuade the customer to defeat the control on their behalf, whether that means tapping ignore, approving a request, disabling a security feature, or simply being told not to worry about the warning. That is precisely why designing a convenient bypass into a security control can quietly change the entire threat model behind it. Industry fraud data describes exactly this pattern, where a customer is talked into installing remote access software or overriding a warning under the belief that they are protecting their own account, and mobile security research documents deceptive interface techniques built specifically to make a customer interact with something other than what they believe they are seeing.¹ A bypass button is therefore not merely a usability feature in that context, since it can become part of the attack itself.

2. The false lesson

Suppose the complaint later enters customer experience reporting and, somewhere in the process of compression, gets distilled into a broader lesson about balancing security and convenience, framed around the importance of giving customers appropriate control while avoiding unnecessary interruptions to their banking journey. Read quickly, that sounds entirely reasonable, and in isolation it might even be right, since security controls can absolutely become too intrusive, false positives matter, and poorly designed warnings create fatigue. NIST’s own research on usable cybersecurity makes the point directly, noting that systems which are too strict end up so burdensome that users intentionally circumvent them, which is exactly the failure mode CX reporting is right to watch for.²

But that would not be the lesson from this incident, because the critical context has disappeared somewhere between the complaint and the summary. The customer was asking for a mechanism that would let someone already warned about suspicious software dismiss that warning and keep banking, and the bank had explicitly explained that a socially engineered customer could then be instructed by a criminal to use that exact bypass. That single piece of context changes the story completely, because the genuine question should have been whether the bank is incorrectly identifying legitimate applications, and if so, how it improves detection without weakening protection for customers who are being actively manipulated. Instead the information compresses down into something closer to security is interrupting the customer journey and we should consider giving customers more control, and although those two framings sound similar on the page, they point in almost opposite directions in practice, and that gap is the false light.

There is also an inversion buried in this complaint that a CX report built purely from inbound feedback will never surface on its own, because on the page a complaint like this looks like negative feedback while in substance it is closer to the opposite. If a fraud control were quietly being bypassed by every customer who found it inconvenient, nobody would be complaining about it, since the control would already be defeated and the fraud would already be happening downstream. The fact that customers encounter this friction at all is therefore evidence that the control is actually binding, in the sense that it is still active and still being enforced, rather than evidence that the control is wrong. It is not, on its own, evidence that the control is effective either. Whether a control is binding and whether a control is effective are two separate questions, and both have to be established before anyone decides what a complaint about it means.

3. Executive compression is where this becomes dangerous

The part that concerns me most is not the original complaint, and it is not the CX interpretation of it either, but what happens after that. Executives are chronically time constrained, and they cannot investigate every social media post, read every customer interaction, or reconstruct every product decision from first principles, which is exactly why organisations build management information in the first place, so that other people can perform that compression on their behalf. That arrangement places an enormous responsibility on whoever is doing the summarising, because when a report labels something a lesson, an executive reasonably assumes the underlying work has already been done. They assume the evidence has been checked, that relevant domain experts have been consulted, that obvious alternative explanations have been considered, that correlation has not quietly become causation somewhere on the journey into a slide, and most importantly that the context left off the slide would not have changed the conclusion had it been included. In this case it would have changed everything.

Imagine an executive reading only the summary. They could reasonably conclude that the bank’s security controls are too restrictive, that customers need greater ability to override them, and that product teams should reduce interruptions, and that conclusion could become a strategic objective that a product owner receives and a team implements. Months later the bank has engineered a bypass into a fraud defence because one unsupported anecdote travelled through the organisation far more efficiently than the threat model behind the control it was undermining. The ship followed the light perfectly, even though it was simply the wrong light.

4. The missing denominator

Almost every complaint arrives as a numerator without a denominator, and that single structural fact explains most of what goes wrong afterwards.

One complaint about a security control could mean one complaint out of twenty customers who hit that control, which would be a serious signal worth acting on quickly. The same complaint could equally mean one complaint out of several million interventions, which is closer to noise and tells you almost nothing about whether the control is calibrated correctly. Those two situations look identical on a slide, because the slide contains the complaint and nothing underneath it.

A complaint system records the people who complained, which is the only thing it was ever built to do. It does not tell an executive how many customers encountered the same control and proceeded without difficulty, how many were genuine false positives, how many abandoned a journey silently instead of writing in, how many were protected from an attack in progress, or what happened to comparable customers who were not subject to the control at all. Every one of those numbers is necessary to interpret the complaint, and none of them arrive with it.

The asymmetry runs one way, which is why this matters so much more than it first appears. Friction generates feedback. Prevention generates silence. A customer stopped unnecessarily knows immediately that they were inconvenienced and is motivated to say so, while a customer whose money was quietly protected may never learn how close they came to losing it, and has little reason to write in about a disaster that did not happen. An inbound customer experience system will therefore tend to observe the cost of a control far more reliably than it observes the benefit of that same control, purely as a function of who bothers to speak up rather than as a function of which experience actually mattered more.

There is research behind this point, and it is worth being precise about what it does and does not say. Work on passively collected customer feedback, meaning the comment cards, toll free numbers and inbound comment links that companies rely on to monitor quality, has long found that these channels have low response rates and are inherently biased, because the customer decides entirely on their own whether to respond.³ More recent research in Management Science documents a related dynamic in online reviews, where the customers who choose to leave feedback differ systematically from those who do not, in ways that skew the aggregate picture a firm derives from them.⁴ None of that means a specific complaint is wrong or exaggerated. It means an inbound feedback stream is not a sample of your customers. It is a sample of the customers motivated enough to contact you, and those are different populations with different distributions of experience.

5. Risk is asymmetric too

The consequences on either side of this decision are not symmetric either, which is the second thing generic customer experience analysis tends to miss. Suppose a fraud control occasionally blocks a legitimate application, which is worth investigating and improving and carries a real cost to the customer, to the brand, and potentially to retention. Now consider the opposite failure, where a vulnerable customer is on the phone with a fraudster who has already convinced them to install software that trips the bank’s protection, the customer sees a warning, and directly underneath it sits the exact button the attacker was hoping for, which is ignore and continue. At that point the attacker no longer needs to defeat the bank’s security control, since they need only defeat the customer’s judgement, and the entire premise of social engineering is that they may already have done exactly that by the time the warning appears.

That is why the honest comparison is never simply friction versus convenience, but rather the probability and cost of incorrectly stopping a legitimate customer weighed against the probability and cost of letting a manipulated customer override a control that exists specifically to protect them, and those are risk questions rather than sentiment questions. OWASP’s mobile security testing guidance reflects that distinction directly, recommending specific defensive mechanisms around sensitive interactions such as login and payment confirmation to prevent attackers from placing deceptive overlays over legitimate screens, while acknowledging plainly that overlay protection does not address a user being deceived through social engineering in the first place.¹ The position this leads to is not that security outranks customer experience, but that an organisation should optimise friction subject to an acceptable level of risk, which is a genuinely different design principle from either extreme.

6. A complaint contains a signal, not a diagnosis

It helps to be explicit about the separate steps that get collapsed into one another whenever this kind of compression happens, because there are really three distinct claims involved, and only the first of them belongs to the customer.

The customer says something happened to them. In this case, a security control prevented them from banking the way they wanted to. That is the signal, and the customer is entirely authoritative about it. Nobody else was there, and nobody else experienced the friction, so their account of what happened to them should be taken seriously and at face value.

The organisation then often turns that signal directly into a diagnosis, something like our security controls create excessive friction, and from there into a prescription, something like give customers an override button. Both of those steps require evidence the complaint cannot supply on its own. A customer is authoritative about the problem they experienced. They are not authoritative about the solution to it, because the solution depends on causes, prevalence and consequences they were never in a position to observe. This control stopped me banking is evidence. Therefore give me an ignore button is a proposed architecture, and the two are not equivalent even when they arrive in the same sentence.

The mistake worth naming, then, is not listening to the customer. It is letting a signal travel all the way to a prescription without anyone doing the diagnostic work in between, work that belongs to fraud, engineering and security rather than to CX reporting or to the customer who raised the complaint.

7. Instrument before you interpret

The obvious response to a complaint like this is to go and ask the fraud team what they think, and that is better than not asking, but it is not sufficient, because the fraud team has its own vantage point and its own incentives. Replacing a customer experience anecdote with a fraud team anecdote is not an improvement in evidence, it is a change of narrator.

The stronger principle is to instrument before you interpret. Before anyone argues about what the control means, establish what the control actually does, which in this case means a fairly specific chain of numbers: alerts generated, confirmed malicious cases among them, legitimate applications incorrectly blocked, override attempts and resulting support calls, customers who abandoned the journey entirely, downstream fraud losses among customers who proceeded anyway, and fraud plausibly prevented among those who stopped. Some of those are harder to measure than others, and the last one in particular requires care, since prevented fraud is by nature a counterfactual rather than an observation. That difficulty is exactly why it needs deliberate measurement rather than assumption in either direction.

Only once that telemetry exists should CX, fraud, cybersecurity and engineering sit down together to interpret it, and it matters that they do so together, because each of those functions can see part of the picture and none of them can see all of it. What this produces is not agreement, which is not the goal, but a shared set of numbers that any subsequent disagreement has to argue against. A genuine defect is entirely possible, and if the detection really is firing on a meaningful slice of legitimate software that needs fixing quickly regardless of how well the control performs elsewhere. The point of instrumenting first is not to win the argument in either direction, but to replace a single anecdote with a denominator before anyone decides what the numerator means.

It also helps to think of this as a ladder that any piece of feedback has to climb before it earns the word lesson, rather than a switch that flips the moment somebody complains.

The mistake is not listening to anecdotes. The mistake is promoting them through that hierarchy without doing the work in between.

8. Four questions before anything becomes a lesson

A complaint like this should absolutely trigger an investigation. It just needs to be the right investigation, and it reduces fairly cleanly to four questions worth working through against the imagined scenario.

The first question is whether what the customer believes happened actually happened. That means reproducing the detection, identifying the specific application or behaviour that triggered it, and establishing exactly why it was classified as suspicious, rather than accepting the customer’s own theory that their intentions make the software safe.

The second question is one of prevalence, since a single social media post tells you that one person is unhappy and almost nothing about scale beyond that. This is where the telemetry from section 7 does its work, by supplying the denominator the complaint arrived without, and it is also where the inversion from section 2 gets tested properly. The investigation will often reveal something the complaint stream structurally cannot, which is that customers who were protected rarely write in to report that the control worked.

The third question asks why the control behaves this way in the first place. That means asking fraud, cybersecurity and engineering why the warning exists, which attack patterns it is designed to catch, and what happens the moment a customer is allowed to override it, and this is also where NIST’s risk assessment guidance is directly useful, since it frames exactly this kind of question around threats, vulnerabilities, likelihood and impact rather than around sentiment.⁵

The fourth question is what happens if a fraudster, rather than the original complainant, is the one standing next to this feature once it ships. If an ignore button existed, a scammer would simply tell a socially engineered victim to tap it the moment the warning appeared, and that question alone would have been enough to stop the proposed fix in this imagined case, because the answer is immediate and obvious.

There should be no lesson before those four questions have answers, though once they do, plenty of outcomes remain possible. The control might really be producing too many false positives, or the explanation shown to customers might need to improve, or the detection might need more precision, or legitimate software might need a safer verification route, or the intervention might already be exactly right as it stands. All of those are conclusions a team is entitled to reach after investigation, and none of them are conclusions anyone is entitled to reach before it.

9. Customer obsession is investigation, not obedience

There is a tendency to treat being customer focused as synonymous with doing whatever the customer asks, and those are not the same thing. A customer may legitimately ask a bank to remove a control that is protecting them from a risk they cannot see, to raise a transaction limit, to weaken an authentication mechanism, to disable a fraud warning, or to allow software that interferes with the secure operation of the banking app. Listening means taking the concern seriously, but it does not mean automatically accepting the proposed solution, and genuine customer obsession sometimes means saying no.

A bank’s responsibility is not only to make today’s transaction frictionless but also to help make sure the customer’s money is still there tomorrow. NIST’s broader research on usable security lands on essentially the same point, since usability and cybersecurity have to be considered together and designing exclusively for either one produces bad outcomes.² NIST’s more recent concept paper on human centred cybersecurity, published in August 2026, pushes this further still, arguing that security guidance should account for people’s needs, abilities and limitations throughout the design and decision making process rather than treating them only as a source of risk to be trained away.⁶

10. The anecdote amplification machine

One anecdote rarely changes a large organisation on its own, though the process built around anecdotes can. If polished customer feedback is routinely elevated into executive reporting without due diligence, an organisation eventually builds what amounts to an anecdote amplification machine, where the person who complains most visibly becomes disproportionately influential and the summary acquires an authority the underlying evidence never supported.

This is particularly dangerous in cybersecurity because attackers are not passive participants in our customer journeys. They observe our controls, discover our exceptions, learn our support processes, find the human workarounds we build in with good intentions, and eventually industrialise them, so that a security exception designed for the rare sophisticated customer who understands exactly what they are doing becomes a script used against the least sophisticated customer we have. When the warning appears, just press ignore is a sentence that should worry anyone responsible for designing fraud controls.

It is also worth noticing that visibility and influence are not the same thing, and the amplification machine does not reliably favour the more visible version of events either. Suppose the bank’s own public reply, the one explaining exactly why the control exists and what a fraudster would do with a bypass, ends up attracting more engagement than the original complaint it was responding to. That correction is now, by any visible measure, the more publicly endorsed account. And yet none of that visibility travels into the executive summary, because the summary was built from the complaint that opened the thread, not from whichever reply the audience ultimately agreed with. The compression pipeline reads the ticket, not the room, so a well substantiated public rebuttal can sit in plain sight, more liked and more shared than the complaint beside it, and still lose the race to become the lesson.

11. Never confuse a complaint with a compass

None of this is an argument against customer feedback. It is an argument for treating customer feedback with enough respect to investigate it properly rather than simply forwarding it upward, since complaints are valuable signals and outliers can reveal defects that aggregate data hides entirely. Security teams need CX input, because security engineers can genuinely become blind to unnecessary friction they have stopped noticing, and the reverse is equally true, since customer experience teams need fraud, risk and security context, because something that looks like unnecessary friction from the outside may be the exact moment a control is preventing a customer from losing their money.

The answer is not for either discipline to dominate the other but for due diligence to happen before anyone declares a lesson, because once information reaches senior executives a short paragraph can carry enormous organisational weight. If we strip out the threat, the evidence, the uncertainty and the context while preserving the recommendation, we have not simplified the information, we have changed its meaning entirely. Executives have to rely on information compressed by others, and that makes the integrity of the compression enormously important. Strip away detail if you must. Strip away words. Strip away slides. But never strip away the context that would change the decision.

A complaint can tell you where to look. Never let one become the compass.

References

1. OWASP Mobile Application Security Testing Guide, MASTG-BEST-0040, guidance on preventing overlay attacks by protecting sensitive interactions such as login and payment confirmation, while noting that these mechanisms address deceptive interfaces rather than social engineering itself. mas.owasp.org/MASTG/best-practices/MASTG-BEST-0040. Industry fraud reporting on technical support and remote access scams in which victims are socially engineered into installing or authorising software that ultimately compromises their accounts, South African Banking Risk Information Centre (SABRIC) consumer scam advisories, sabric.co.za.
2. NIST Usable Cybersecurity research, National Institute of Standards and Technology, on the coexistence of usability and security and the risk that overly burdensome controls lead users to circumvent them. csrc.nist.gov/projects/usable-cybersecurity.
3. Research on passively solicited customer feedback such as comment cards and toll free numbers has documented low response rates and self-selection among respondents, since companies have little control over who chooses to respond. See discussion of this literature in Ramifications of Monitoring Service Quality Through Passively Solicited Customer Feedback, summarising earlier work including Sampson (1996) and Barsky (2001).
4. Chen, N., Li, A., and Talluri, K. (2021), Reviews and Self-Selection Bias with Operational Implications, Management Science, 67(12), documenting how self-selection among reviewers can bias the aggregate picture a firm draws from customer reviews.
5. NIST Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments, on structuring risk assessment around threat sources, vulnerabilities, likelihood and impact. csrc.nist.gov.
6. NIST, Human Centered Cybersecurity Guidelines and Resources Concept Paper, published August 2026, proposing guidance that accounts for people’s needs, abilities and limitations throughout the design, deployment and decision making stages of cybersecurity, rather than treating people only as a source of risk. csrc.nist.gov/pubs/other/2026/08/12/human-centered-cybersecurity-guidelines-and-resour/final.