Why do interceptable authentication methods increase scam liability for banks?

Because liability now depends on whether the bank used adequate controls, not just whether the customer entered a code. Interceptable methods such as SMS OTP can be defeated outside the bank’s trust boundary, which makes them hard to defend as strong authorisation for high-risk activity.

Why This Matters for Security Teams

Interceptable authentication methods change the liability picture because they are often treated as proof of user approval even when the control can be redirected, cloned, or socially engineered outside the bank’s environment. That creates a gap between what the system recorded and what a court, regulator, or disputes team may consider adequate authentication for high-risk transfers, beneficiary changes, or account takeover remediation.

Security teams should read this through the same lens used for NIST SP 800-53 Rev 5 Security and Privacy Controls: not every credential proves intent, and not every proof survives adversary interference. The issue is especially sharp when SMS OTP, voice callbacks, or other interceptable factors are used as the main authorisation signal for a transaction that should have stronger step-up verification. NHI Mgmt Group’s research shows that secrets and identity materials routinely escape controlled boundaries, as seen in incidents such as the Twitter Source Code Breach, where access pathways and operational trust assumptions were part of the failure surface. The same lesson applies to customer authentication when the control can be broken before the bank ever sees a denial.

In practice, many security teams encounter liability only after a disputed payment is reversed, rather than through intentional control design.

How It Works in Practice

The liability problem starts with the bank’s evidence model. If a customer receives a one-time code over SMS, an attacker who has SIM-swapped the number, intercepted messages, or socially engineered the victim can still complete the challenge while the bank logs a “successful” factor. That log entry may satisfy an internal workflow, but it does not necessarily prove the customer had exclusive control of the factor or understood the transaction.

For higher-risk actions, current guidance suggests moving away from single, interceptable signals and toward stronger, layered controls. In practice that means:

• Using phishing-resistant factors for step-up events, not just for login.
• Binding authentication to the transaction context, such as payee, amount, and device state.
• Applying out-of-band review only when the channel itself is resistant to interception.
• Logging evidence that supports both security review and dispute handling, not just authentication success.

This is where banks often separate “authentication” from “authorisation.” A code can help verify possession of a channel, but it does not always verify intent, and intent is what matters in scam-liability assessments. ISO control systems are helpful here because they force consistency in risk treatment, monitoring, and exception handling; see ISO/IEC 27001:2022 Information Security Management for the governance baseline. The same principle is reflected in NHI operations, where exposed or hard-coded secrets create false confidence until an attacker turns that trust into abuse, as demonstrated in the Gladinet Hard-Coded Keys RCE Exploitation research.

These controls tend to break down when customer support processes can reset identity or swap contact channels without strong verification, because the attack path moves from technical interception to procedural compromise.

Common Variations and Edge Cases

Tighter authentication often increases friction and dispute-handling cost, requiring organisations to balance fraud reduction against customer abandonment and operational overhead.

There is no universal standard for this yet, so banks should treat channel quality as a risk factor rather than assuming all OTPs are equivalent. App-based push approvals, number-matching prompts, and cryptographic transaction signing can materially improve assurance, but each has edge cases. Push fatigue can be abused, device compromise can undermine app trust, and a strong factor used on a weak recovery path can still leave the bank exposed.

Another nuance is evidentiary. A method may reduce fraud even if it does not eliminate all scam liability. What matters is whether the bank can show reasonable, proportionate controls for the transaction class and customer segment. That is why many institutions are reassessing legacy SMS flows, especially for first-time payees and high-value transfers, while preserving fallback paths only with stronger recovery checks and fraud analytics. NHI Mgmt Group’s broader guidance on secret governance underscores the same lesson: once trust material can be intercepted or reused, the control is no longer as strong as the team assumes, and the risk narrative shifts quickly.

For banks handling cross-border payments or older mobile populations, the practical tradeoff is that the safest factor may not be the most usable factor, so policy must account for customer impact as well as loss exposure.

Related resources from NHI Mgmt Group

• Why do Salesforce integrations increase NHI risk?
• Why do legacy recovery methods often increase authentication risk?
• Why do standing privileges increase lateral movement risk so much?
• Why do compromised identities increase business interruption risk?