What do banks get wrong about passwordless authentication and fraud prevention?

They often assume passwordless login removes the fraud problem, when it only removes one attack path. Fraudsters can still exploit real-time phishing, adversary-in-the-middle tactics, or transaction tampering after authentication. Effective controls must protect both identity verification and the content of the transaction being authorised.

Why This Matters for Security Teams

passwordless authentication is often positioned as a fraud cure, but that framing is too narrow for regulated banking environments. Removing passwords can reduce credential stuffing and phishing against static secrets, yet it does not eliminate session hijacking, real-time adversary-in-the-middle attacks, mule-account abuse, or manipulation of the payment step after login. A stronger view is to treat passwordless as one control in a wider identity and transaction-risk strategy, consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls.

For banks, the real issue is that authentication proves a person or device reached a session, not that the subsequent action is legitimate. Fraud teams care about beneficiary changes, device binding, behavioural anomalies, and authorisation integrity, while IAM teams often focus only on login success. That gap leaves room for attackers to exploit trust established at sign-in and then pivot into payment initiation, account takeover, or profile changes. In practice, many security teams encounter this only after a “successful” passwordless rollout has already shifted fraud loss into downstream transaction abuse, rather than through intentional fraud design.

How It Works in Practice

Effective passwordless fraud prevention starts by separating three questions: who is authenticating, what device or session is being trusted, and what transaction is being approved. FIDO2, passkeys, and device-bound authenticators can materially raise the bar for credential phishing, but they should be paired with step-up checks for risky events and with transaction signing or strong confirmation for high-value actions. The security model should assume that an authenticated session can still be coerced, proxied, or reused.

Operationally, banks should bind authentication to context and risk signals. That typically includes device reputation, geolocation anomalies, IP intelligence, behavioural biometrics where appropriate, and explicit verification of payee details or transfer amount before release. Controls should also feed fraud analytics and case management, not sit only inside the access stack. Alignment with ISO/IEC 27001:2022 Information Security Management helps ensure the control set is governed, tested, and reviewed rather than treated as a one-time rollout.

• Use phishing-resistant authenticators, but do not assume they neutralise real-time proxy attacks.
• Require transaction-level confirmation for new beneficiaries, limit increases, and unusual payment patterns.
• Correlate authentication telemetry with fraud and SIEM alerts so suspicious sessions are visible in both teams.
• Apply step-up verification only where risk warrants it, to avoid degrading legitimate customer journeys.

For cross-border or regulated digital identity flows, banks should also consider interoperability and assurance expectations from eIDAS 2.0 — EU Digital Identity Framework. These controls tend to break down when authentication is modernised faster than payment-risk orchestration, because the fraud stack still trusts the session more than the action.

Common Variations and Edge Cases

Tighter transaction controls often increase friction, requiring banks to balance fraud loss reduction against abandonment, support load, and customer trust. That tradeoff is especially visible in retail banking, where low-value activity should not be treated like high-risk wire transfers, and in corporate banking, where authorised signers may already operate under complex approval chains.

Best practice is evolving for agentic and delegated flows, because an AI assistant or embedded finance workflow may legitimately initiate actions without a human present. In those cases, the bank needs stronger policy around scope, consent, and delegated authority than a simple login policy can provide. The same principle applies when a passwordless session is reused across device handoff, call-centre-assisted recovery, or recovery-factor reset paths, all of which can become the weakest point in the chain.

Fraud prevention also needs to reflect AML and KYC obligations. Identity assurance, customer due diligence, and anomaly detection should reinforce each other rather than operate as separate programs, consistent with FATF Recommendations — AML and KYC Framework. There is no universal standard for this yet, but current guidance suggests treating passwordless as a stronger front door, not as proof that the entire banking interaction is safe.

Related resources from NHI Mgmt Group

• What do organisations get wrong about fraud prevention and authentication?
• What do security teams get wrong about passwordless authentication and AI risk?
• What do security teams get wrong about passwordless authentication?
• What do security teams get wrong about passwordless authentication in regulated environments?