How Banks Can Break Client Hypnosis: Contextual Authorisation and the Fight Against Social Engineering Fraud

Contextual authorisation breaks social engineering fraud by injecting friction at the precise moment a customer is psychologically captured, forcing the brain to re-engage analytical thinking before approving a transaction. Rather than relying on warnings customers cognitively bypass under manipulation, banks must present authorisation prompts that demand genuine comprehension, disrupting the automatic compliance state fraudsters deliberately induce.

by Andrew Baker

1. Opening: The Client Has Been Captured

The fraud victim approving a transaction they believe is a refund is not making a mistake. They are not confused or careless or naive. They are operating under full psychological capture, executing instructions from an authority figure they have been conditioned over the course of a phone call to trust absolutely, in a cognitive state where their rational analytical mind has been effectively sidelined and their automatic compliance system is running the show. They are, in the most clinically accurate sense of the term, not fully present at the moment they tap approve.

This distinction matters enormously for how banks design fraud controls, because almost no intervention currently deployed accounts for it. The warnings are there. The information is on the screen. The client is not reading it because they have been taken somewhere else, and a margin nudge will not bring them back. They need awakening.

This article is about what banks should build, at the authorisation layer, to interrupt that captured state at the precise moment it would otherwise result in an irreversible payment.

2. Two Different Problems: Identity and Decision

Before designing any fraud intervention it is worth being precise about which problem you are actually solving, because banks routinely conflate two distinct challenges and end up building the wrong thing.

The first problem is identity: is the person initiating this transaction actually the account holder? This is an authentication question, and while it is not trivial it is broadly a solved problem. Biometric verification, device binding, step-up challenges using facial recognition, and account locking mechanisms give banks robust tools to establish that the person behind the screen is who they claim to be. When a bank suspects account takeover, these tools work.

The second problem is decision quality: is the account holder acting freely and with an accurate understanding of what they are doing? This is an authorisation question, and it is dramatically harder than the first because the customer’s identity is valid, their device is known, their biometrics match, and they are genuinely choosing to approve the transaction. The problem is that they have been psychologically captured. They are no longer the autonomous decision maker they appear to be. They are an instrument executing instructions issued by someone else, and the authorisation flow was designed for a person who is present and thinking, not for a person in this state.

Account takeover is hard to execute at scale precisely because identity controls have matured. Psychological capture is easy to execute at scale because almost no bank has built meaningful controls at the decision layer, and that is the gap this article addresses.

It is also worth naming a third failure that sits underneath both of these: the shared secret. Banks have spent decades building identity controls on top of credentials that are, by design, shared. A card number, expiry date, and CVV are not secrets in any meaningful sense because completing a standard card transaction requires you to hand all three to a merchant, a payment terminal, or a website. A PIN is marginally better but is routinely entered in public on devices that may be compromised. An OTP is transmitted as plaintext over a carrier network, unencrypted, across infrastructure the bank does not own or control, and subject to SIM swap, SS7 interception, and social engineering of the mobile operator itself. A bank placing total reliance on an SMS OTP as its primary authentication control is not building a security architecture, it is outsourcing trust to a telecommunications carrier and hoping for the best. An OTP can be one leg of a layered approach combined with device binding, behavioural context, and transaction risk scoring, but as a standalone control it is inadequate and the industry has known this for years.

When a customer is socially engineered into revealing these credentials, the bank’s response is often to suggest that the customer should not have shared their details, which is a remarkable position given that sharing those details is precisely what the payment system requires. Blaming a customer for complying with a social engineer who asked them to do exactly what every legitimate transaction also asks them to do is not a security argument. It is liability transfer dressed up as advice.

3. The Neuroscience of Capture: Why Smart People Disappear

Understanding why psychological capture happens requires a brief excursion into how the brain actually makes decisions under pressure, because the common security industry assumption, that more information or better warnings will fix this problem, is built on a fundamental misunderstanding of human cognition.

Daniel Kahneman’s framework, developed over decades and awarded the Nobel Prize in Economics in 2002, describes two modes of thinking. System 1 is fast, automatic, and unconscious, handling roughly 95 percent of all decisions without deliberate effort. It recognises patterns, responds to authority, and acts on social cues before conscious reasoning has time to engage. System 2 is slow, deliberate, and analytical, capable of reading a screen carefully, weighing a decision, and questioning an instruction from someone claiming to be from a bank fraud team. The social engineer’s entire craft is the suppression of System 2 and the hijacking of System 1.

They do this through a sequence of well-documented psychological mechanisms. Urgency and fear activate the amygdala, which floods the brain with stress hormones that degrade the prefrontal cortex’s capacity for analytical reasoning, the exact region responsible for System 2 thinking. Authority cues, such as a caller who knows the victim’s bank, account type, and a recent transaction, trigger automatic compliance responses that neuroscience consistently shows activate faster than deliberate reasoning. Research by NINJIO confirms that attackers deliberately synchronize these techniques with business stress points to amplify cognitive overload, targeting the moment when the victim’s System 2 capacity is already depleted.

Stanley Milgram’s obedience experiments in the 1960s demonstrated what happens when these conditions are met at scale. Ordinary people, when placed under the authority of a perceived expert and subjected to gradual escalation of demands, entered what Milgram described as an agentic state: a condition in which they no longer perceived themselves as responsible for their own actions but experienced themselves as instruments executing the wishes of the authority figure. The Wikipedia analysis of Milgram’s work notes that participants in this state showed measurable signs of internal conflict, including nervous laughter, sweating, and trembling, while continuing to comply. They were not without awareness. They were captured, and awareness was not enough to free them.

This is precisely the state a socially engineered banking customer is in when they tap approve. They may feel vaguely uncomfortable. They may have a passing sense that something is unusual. But the authority figure on the phone has structured the situation so that their System 2 objections are overwhelmed by System 1 compliance, and they execute the instruction. A warning message they have seen a hundred times before does not reach them in this state. It is pattern noise. It registers as familiar, which means it registers as safe, which is the opposite of what it is designed to communicate.

The ScienceDirect interdisciplinary review of social engineering literature further identifies how attackers exploit attention hijacking, working memory saturation, and decision-making shortcuts to ensure the victim’s analytical capacity remains offline for exactly the duration required to complete the transaction. By the time System 2 reasserts itself and the victim begins to question what happened, the money has moved.

Designing for this state requires interventions that are not legible to System 1 as normal. If it looks the same, feels the same, and follows the same sequence as every other transaction, System 1 will process it as safe and the captured client will click through it without registering its content. The intervention has to break the pattern so completely that it forces a System 2 reactivation, a moment of genuine cognitive dissonance strong enough to surface through the captured state and give the real person a chance to reassert themselves.

4. The Problem With Static Security UI

Banks deploy the same authentication message on every transaction, and the message is technically correct: the information is there. But the captured client does not see it, and this is not carelessness but precisely how psychological capture is designed to work. Cognitive load theory establishes that when users see the same interface repeatedly their brain stops processing it as new information and treats it as pattern noise, and a client who has been deliberately placed into a state of narrowed perceptual awareness and heightened suggestibility is not going to break out of that state because the approve button looks the same as it always does.

There is also a more cynical failure mode worth naming directly. Many banks design these screens not to protect clients but to protect themselves, deploying warnings as an accountability offloading exercise so that when a client is defrauded the institution can point to the screen and say the information was there in plain English. The result is language drafted by compliance teams optimised for defensibility rather than comprehension, in formats that a client operating in a captured state has no realistic chance of processing. A catch-all disclaimer that claims to cover every possible fraud scenario is both naive as a design choice and contemptuous toward the clients it claims to protect, because it prioritises the bank’s ability to disclaim liability over the client’s ability to re-engage with reality.

Warnings that actually work have to be designed by fraud and customer experience experts working together, built around specific MOs rather than generic risk language, and capable of being updated quickly as the fraud landscape changes. A social engineering MO can emerge, scale across thousands of victims, and evolve into a new variant within weeks. A bank whose warning screens are locked inside a legal approval process measured in months will always be behind. The ability to spin up a new contextual warning rapidly, targeted at a specific emerging MO, is as much a fraud control capability as any detection algorithm.

5. The Signal Taxonomy: What the System Needs to See

Contextual authorisation is only as intelligent as the inputs feeding it. The following categories describe the types of real-time context a well-designed system should evaluate at the point of transaction, ranging from device-level observations through to network-level novelty measures.

No single category is sufficient on its own. The system scores each available indicator against the customer’s established baseline and the network-wide norm, compounds those scores, and routes the transaction based on whether the resulting risk profile crosses the threshold for intervention. Critically, none of these indicators need to be stored as a persistent record of customer behaviour. A zero knowledge proof approach, explained further in section 9, allows the system to verify that a condition is true without retaining the underlying data that would allow reconstruction of a detailed behavioural profile. The system can know enough to act without recording enough to surveil.

6. Why Now: Cloud, AI, and the End of the Blunt Instrument

The framework described in this article is not new in concept. Security researchers and fraud practitioners have understood the psychology of social engineering capture for decades, and the idea of contextual, adaptive authorisation has existed in academic literature for years. The reason it has not been widely deployed is not lack of imagination. It is lack of precision.

Expert rules engines, the traditional mechanism for flagging anomalous transactions, are too blunt to do this well. A rule that fires on every new beneficiary, or every unregistered browser, or every transaction above a certain threshold, will detonate on legitimate customer behaviour so frequently that the intervention loses all meaning within weeks. The airbag analogy is exact: an airbag that deploys every time you drop your shopping on the back seat does not protect you in a crash, it just trains you to disable the system. Precision is not a nice-to-have in contextual authorisation design. It is the entire point. Without it, you recreate the habituation problem you were trying to solve, at greater cost and with greater customer frustration.

What has changed is the infrastructure available to build the precision layer. Cloud-scale data platforms now allow banks to maintain rich, real-time behavioural profiles across millions of customers simultaneously, something that was operationally and economically impractical in on-premise architectures. Machine learning models trained on network-wide transaction patterns can identify compound anomaly signatures with a specificity that static rules cannot approach, distinguishing the transaction profile of a socially engineered victim from a legitimate customer making an unusual payment with a granularity that reduces false positive rates to a level where the intervention remains rare enough to be effective. Real-time stream processing means that the compound risk score for a transaction can be computed and acted on in milliseconds, before the authorisation screen is rendered, rather than as a post-transaction review.

AI also changes the speed at which the system can adapt to new MOs. A new social engineering pattern that produces a distinctive compound signal signature can be identified in near real time across the transaction network, a new divergence point can be computed, and the risk pathway can be updated to intercept it, all within a timeframe measured in hours rather than the months a traditional rules change process would require. This matters because the asymmetry of the current situation is stark: attackers iterate their MOs in days, and banks respond in quarters.

None of this is trivial to build. Getting contextual authorisation right requires sustained investment in behavioural data infrastructure, model development, signal calibration, device registration architecture, and the operational tooling to give fraud teams real-time visibility into the risk pathway population. It requires the kind of cross-functional commitment that brings together fraud operations, data engineering, product design, customer experience, and legal, and it requires a tolerance for the iterative work of tuning signal weights and retiring noisy indicators until the false positive rate is low enough that the intervention retains its psychological impact. This is not a project. It is a capability, and building it properly takes years of deliberate effort. The industry owes it to its clients to start.

7. Contextual Authorisation: Designing the Circuit Breaker

A contextual authorisation system does not add friction to every transaction but reserves intervention for transactions where the compound risk profile deviates meaningfully from the customer’s established baseline and from network-wide norms. When that threshold is crossed, the goal is not to inform the client but to reawaken them: to create a rupture in the captured state severe enough that System 2 can reassert itself before the payment completes.

6.1 The Pre-Auth Narrative Check

Before showing the payment authorisation, the system surfaces a single, short, high-contrast question: “Is someone from a bank fraud team calling you right now?” with two buttons, yes or no, no dismiss option, and no ability to proceed without answering.

This screen is designed to do one thing: name the attack while the client is still in it. The social engineer has constructed an entire reality in which this call is legitimate and the transaction is necessary. A direct question that explicitly names the possibility that the call is fraudulent is a direct attack on the architecture of that reality. For a client in a captured state, it is the first external signal that contradicts the narrative they have been given, and that contradiction is the beginning of reawakening.

If the answer is yes, the transaction is halted immediately and the client is routed to a live fraud agent or the account is suspended pending verification.

The design of this screen requires the same precision as the detection logic behind it. A well-executed example surfaces the anomaly first in plain language, something like “we have picked up activity from an unknown browser,” so the client understands why they are being asked before they are asked. It then states the bank’s position unambiguously, in bold, that the fraud team will never call a client to approve anything in the app. It then asks the binary question directly. Critically, the button hierarchy matters: the no button should be the visually dominant option, filled and prominent, because a captured client primed to tap yes should have to make a deliberate choice to do so rather than following the path of least visual resistance. Every element of this screen is a design decision with a fraud outcome attached to it, and it should be treated as such.

6.2 The Delayed Auth Screen With Color Coding

The auth screen that follows anomalous transactions must look materially different from the standard auth screen, with a changed color scheme, a different layout, and the risk context surfaced explicitly: “You are paying a beneficiary this bank has never paid before. You are using a browser you have not used before.”

The buttons are disabled for five seconds. The social engineer will have told the client that a screen is about to appear and to click okay immediately. The enforced pause is not a UI convention. It is a forced interruption of the automatic response loop that has been installed by the social engineer, a deliberate attempt to create the temporal space in which System 2 can re-engage. Forced pauses are already standard in safety-critical systems precisely because automatic compliance under authority pressure is a known and documented human failure mode, and five seconds of enforced waiting, combined with a screen that looks nothing like normal, is sometimes enough to break the surface of the captured state.

The content must be minimal. Two sentences and a number. A client in a captured state who has been told to click through will not read a paragraph, but they may read two sentences if those sentences are large, stark, and visually alarming enough to register as something genuinely different from everything they have seen before.

6.3 Contextual Shipping: Rendering the Truth on Screen

The more powerful design move is to render the transaction as a progressive sequence of direct contradictions to the false reality the attacker has constructed. Each statement should be a factual collision with the narrative the client has been given.

The pre-auth check names the attack: “Is someone from the bank calling you?” The auth screen states the transaction: “You are sending R18,000.” It shows the outcome: “Your balance becomes R3,200.” It closes the loop: “No money will enter your account from this transaction.”

A client who has been told they are receiving a refund, or moving money to a safe account, or reversing a fraudulent transaction, is now looking at four sentences that are factually incompatible with every element of the story they have been told. The social engineer has spent the entire call constructing a coherent false reality. The screen dismantles it in four lines. For some clients, that collision is enough. System 2 re-engages. They hesitate. They feel the dissonance. They do not click.

6.4 The Thought Experiment: What Best in Class Looks Like

Imagine the app detects the following simultaneously: the microphone is active, indicating the client is on a call; the beneficiary was added less than five minutes ago; the transaction amount is significantly above the customer’s typical single payment; and the beneficiary account has never been paid by anyone at the bank before.

In a standard authorisation flow, the client sees an approval screen and clicks through under instruction from the social engineer. In a best in class contextual authorisation flow, the system does not show an approval screen at all. Instead it shows a single message: “We have paused this payment. Please hang up, wait two minutes, and we will call you back on your registered number to verify this transaction.”

The social engineer cannot coach the client through that screen because it removes the client from their control entirely. The callback comes from the bank on a verified channel. The client either confirms the payment with full understanding or, far more likely, the two minute pause is enough for the captured state to dissolve on its own. This is not a futuristic concept. The capability to detect microphone activity, score compound anomalies in real time, and trigger a callback workflow exists today. The gap is not technical. It is organisational will.

8. The Merged Path Problem: Splitting the Fraud Flow Before You Load It

One of the most common implementation mistakes in contextual fraud controls is loading warnings and friction onto a path that legitimate customers and captured clients share equally. When a fraud MO is active, the transaction flows for a genuine customer and a social engineering victim often look completely identical up to the point of authorisation. If you respond by adding friction to that shared path, you degrade the experience for a large population of legitimate customers to reach a small population of captured clients, and in doing so you accelerate the exact habituation problem the rest of this article is trying to solve.

The correct approach is to fracture the population before you load it with friction. Analyse the specific fraud MO to find the attribute or combination of attributes unique to the fraud flow that does not appear in the legitimate flow at meaningful frequency. That divergence point is where you insert the split. Only the population whose transaction profile matches the MO signature gets routed onto the risk pathway. Everyone else continues on the standard path without additional cognitive load.

Finding that divergence point requires genuine MO analysis rather than generic anomaly thresholds. A new beneficiary alone is not a divergence point if your customer base routinely pays new beneficiaries. The combination of a new beneficiary, an unregistered browser, and a transaction amount exceeding the customer’s typical single payment threshold might be. The compound specificity of the MO signature is what allows you to fracture the population narrowly enough that the risk pathway screens remain rare and therefore retain their capacity to shock System 2 back into operation when they do appear.

Once you have split the population, your fraud operations team needs real-time visibility: which clients are on the risk pathway, how many at each stage, how many abandoning, proceeding, or answering yes to the narrative check. This does not require a complex data warehouse project. A lightweight dashboard assembled quickly from your existing event stream, showing the risk pathway population as a live funnel, gives your fraud ops team what they need to intervene manually where the system has flagged but not blocked. The speed at which you can build and iterate that observability layer matters as much as the sophistication of the underlying detection, because fraud MOs evolve quickly and your ability to observe a new pattern in production is what lets you tune the divergence criteria before significant losses accumulate.

Push the fraud flow away from the merged path before you put anything on it, keep the risk pathway population as narrow as the MO signature allows, and make sure your fraud ops team can see that population moving through the funnel in real time.

9. The Anomaly Management Problem and the Infrastructure That Underpins It

A system that triggers contextual authorisation on the same customer repeatedly will train that customer to dismiss it, replicating the exact problem it was designed to solve. Anomaly management is therefore as important as anomaly detection.

The system must build individual behavioural profiles that determine which indicators are genuinely anomalous for each specific person. The traveling salesman who uses a new browser daily gets that indicator deprecated from their profile, while the new beneficiary indicator stays hot for everyone because it is a network-level novelty measure that does not vary by individual customer behaviour pattern. Indicators that fire too frequently for specific customers must be retired from their trigger set while the platform’s overall protective power is preserved for the indicators that remain genuinely anomalous.

This requires infrastructure that most banks have not yet deliberately built. Consider the browser indicator. Customers should be free to bank from any browser at any time, but in practice most people use the same browser repeatedly, and you cannot know this without a system that lets them tell you. A browser registration flow, typically one or two screens, allows a customer to explicitly mark a device as trusted. The registration is written locally using cryptographic methods through Web Authentication APIs, binding it to that specific hardware in a way that cannot be trivially replicated.

When a payment originates from an unregistered browser, both the bank and the customer understand this is not normal. The customer can register it for future use or proceed knowing it will attract additional scrutiny. Someone banking from a cafe overseas does not want to register that device, and the system accommodates that choice while preserving the anomaly value of the unregistered browser for that session.

Behavioural profiling platforms like ThreatMark and SEON establish that the quality of anomaly detection is directly proportional to the richness of the behavioural baseline, built through sustained, non-intrusive data collection across login patterns, transaction behaviours, device usage, and navigation paths. You cannot retrofit this onto an existing platform that was not designed for it. You have to design the system around your clients from the outset in a way that does not annoy them but allows you to understand, over time, what normal looks like for each of them individually.

10. Privacy, Data, and the Case for Ephemeral Decisioning

A reasonable objection to the signal taxonomy described above is that collecting behavioural context at the transaction layer starts to look like surveillance. That objection deserves a direct answer.

The architecture this article proposes does not require a persistent database of customer behaviour. The signals described, microphone activity, device registration status, beneficiary novelty, transaction amount relative to baseline, are computed at the point of decision and consumed there. They do not need to be stored in a form that allows reconstruction of a detailed behavioural profile.

The cryptographic approach that makes this possible is called a zero knowledge proof. In plain terms, a zero knowledge proof allows a system to verify that a statement is true without revealing the underlying data that makes it true. Instead of storing a record that says “this customer has used this browser 47 times,” the system stores a cryptographic commitment that allows it to answer the question “has this browser been seen before?” with yes or no, without retaining any data about when, how often, or in what context. The verification happens. The surveillance does not.

This matters beyond privacy preference. Regulators examining automated decision making in financial services are increasingly focused on whether data used in those decisions is proportionate to the purpose, explainable to the customer, and not retained beyond operational necessity. An ephemeral decisioning architecture satisfies all three of those tests more cleanly than a traditional behavioural database. The bank can explain what it checked, confirm it did not store what it did not need, and demonstrate that the intervention was proportionate to the risk profile of that specific transaction.

11. How You Know It Is Working

Designing this system without a measurement framework means building on intuition rather than evidence. The following metrics collectively tell you whether contextual authorisation is doing its job without creating new problems.

Fraud prevented measures the volume and value of transactions halted or reversed where contextual authorisation was triggered, compared to a control group or prior baseline, and is the primary outcome measure. False positive rate tracks the proportion of contextual authorisation triggers that were legitimate transactions, measured through customer complaint volumes, abandonment at the anomalous auth screen, and post-transaction reversal requests. Too high a rate means you are training customers to ignore the intervention. Abandonment delta measures the difference in transaction completion rates between standard and contextual authorisation screens, where a small increase is acceptable but a large one means the screen is too disruptive for legitimate customers.

Repeat fraud attempt rate tracks whether the same social engineering method is being attempted again after a contextual authorisation block, with a declining rate suggesting the approach is changing attacker behaviour rather than just blocking individual transactions. Anomaly retirement rate measures how quickly the system learns each customer’s baseline and retires weak or noisy indicators, where a healthy system shows rapid early retirement followed by stability. Time to completion delta captures the real cost of the five second delay and additional screen, and should be measured against fraud value prevented to establish whether the friction is economically justified.

The economic case is straightforward. Take the value of fraud prevented, subtract the cost of increased abandonment on legitimate transactions, subtract the operational cost of manual review on flagged cases, and the remainder is the net value of the programme. Banks that have deployed risk-based friction consistently find that even modest reductions in high-value fraud events produce a strongly positive net figure, because the transactions being targeted are disproportionately large relative to the volume of legitimate transactions disrupted.

12. The Broader Design Principle: Difference Is the Reawakening

When you see a red and yellow snake, your brain registers danger without needing to identify the species. The visual pattern is different from what you normally encounter and your brain responds to the difference itself before conscious reasoning has time to engage. That response is involuntary. It bypasses the captured state. It arrives before the authority figure on the phone can intercept it.

This is the underlying principle behind contextual authorisation as a fraud control. The authorisation screen on an anomalous transaction needs to look like that snake, different enough that even a client in a fully captured state experiences an involuntary rupture in their compliance loop. That rupture is the opening. The five second delay holds it open. The minimal stark content focuses it. The progressive contradiction sequence fills it with facts that are incompatible with the story they have been told. The pre-auth narrative check names the attack before they ever reach the payment screen.

None of this is certain to bring every client back. A sufficiently skilled social engineer can prepare a victim for almost any screen, and the goal is not perfection but rather to create enough difference, at the right moment, in the right form, to give the real person trapped inside the captured state one more chance to surface before the money moves.

13. Conclusion

Social engineering succeeds not because victims are weak but because skilled attackers are capable of temporarily suspending the rational decision-making capacity of any human being under sufficient authority pressure and stress. The neuroscience is unambiguous on this. The client who approves a fraudulent payment is not making a considered decision. They have been captured, and they need to be brought back.

Identity can be valid while intent is compromised, and that is the problem that static authentication was never designed to solve. Contextual authorisation addresses it directly as a precision intervention, triggered by compound anomalies, designed to surface enough difference at the right moment to rupture the captured state before the payment completes. Building it properly requires investment in behavioural data infrastructure, device registration architecture, and the change management to bring customers along, because the UI is the visible part and the real work happens underneath it.

Design for the moment when the person needs to come back.

References