Phishing-resistant transaction signing is becoming core banking control

At a glance

What this is: This article argues that phishing-resistant transaction signing is now a core banking security control, because modern fraud increasingly targets both credentials and transaction integrity.

Why it matters: It matters to IAM, PAM, fraud, and identity teams because customer authentication alone does not protect high-value transactions if adversaries can alter or replay the action after login.

By the numbers:

• In 2023, phishing attacks surged by 58.2% year over year.
• In the US and Canada, every $1 lost to fraud costs financial services organisations $4.61.
• In Japan, 39% of surveyed individuals reported financial losses due to scams in 2024.

👉 Read OneSpan's article on phishing-resistant transaction verification for banking

Context

Phishing-resistant banking security is best understood as the shift from user authentication to transaction assurance. The article’s core claim is that fraud teams can no longer rely on passwords, OTPs, or even login-level MFA when attackers increasingly use phishing, smishing, adversary-in-the-middle techniques, and message manipulation to change the transaction itself. That is a governance problem as much as a fraud problem.

For identity practitioners, the intersection is clear: customer identity, step-up authentication, and transaction signing are now part of the same control plane. Once an attacker can steal a session or alter the destination account before approval, the question is no longer whether a user authenticated, but whether the transaction was bound to the intended action on a trusted device.

Key questions

Q: What breaks when banks rely on login MFA instead of transaction signing?

A: Login MFA proves that a user authenticated, but it does not prove that the payment details were unchanged at approval time. Attackers can still manipulate the transaction in the browser, intercept the session, or alter the destination after login. Transaction signing binds the action itself, which is what stops fraud when the user identity has already been established.

Q: Why do phishing-resistant authenticators matter for financial transactions?

A: They reduce the chance that reusable credentials or one-time codes can be stolen and replayed during a fraud attempt. That matters most in high-value banking flows, where attackers combine phishing, social engineering, and session abuse. The goal is not only to verify the customer, but to preserve the integrity of the transaction they approve.

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

A: 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.

Q: How should security teams decide when to use transaction signing?

A: Use it whenever a transaction is financially material, hard to reverse, or vulnerable to payee or amount manipulation. The more costly the fraud and the less recoverable the payment, the more the approval step should bind the exact details being signed. That is where transaction assurance becomes a first-line control.

Technical breakdown

Why phishing-resistant authentication is not enough on its own

Phishing resistance reduces the chance that a user will hand over reusable credentials, but it does not automatically guarantee transaction integrity. In banking, attackers often operate after authentication by intercepting the session, changing destination details, or coercing approval through real-time phishing and social engineering. That is why passwordless login, FIDO assertions, and OTP replacement help, but they must be paired with transaction binding. Without that link, the authentication event proves only that a user was present, not that the payment details remained unchanged.

Practical implication: banks should treat authentication and transaction verification as separate controls, not one combined outcome.

How transaction signing and WYSIWYS change the trust model

Transaction signing creates a cryptographic or visual proof that the payer reviewed a specific set of details, such as account number and amount, before approval. The WYSIWYS model, what you see is what you sign, is designed to stop adversary-in-the-browser attacks where the displayed transaction differs from the one actually transmitted. Cronto-style cryptograms add a trusted, out-of-band visual check on a secure device, which makes post-login manipulation harder. The key security property is transaction integrity, not just identity proofing.

Practical implication: use signing workflows for high-value and high-risk transactions where destination tampering would be costly.

Why replay resistance and secure key storage matter in fraud controls

Replay resistance prevents an intercepted authentication response from being reused in a later session, which is critical in environments exposed to man-in-the-middle fraud. Secure key storage on the authenticator limits the blast radius of server compromise because the private material needed to generate or verify proofs is not broadly exposed. This matters in regulated banking because attackers increasingly combine endpoint compromise, phishing, and server-side abuse. A control that survives one layer failing is more valuable than one that assumes every layer will hold.

Practical implication: prioritise authenticators and signing methods that resist replay and keep key material off general-purpose endpoints.

Threat narrative

Attacker objective: The attacker wants to authorise a fraudulent transaction while making the victim believe the original payment details were approved.

1. Entry begins with phishing, smishing, or adversary-in-the-middle interception that captures credentials or session data before the transaction is finalised.
2. Escalation occurs when the attacker manipulates the transaction details in-browser or abuses a live session to change the payee, amount, or approval path.
3. Impact follows when the altered transaction is signed or approved, allowing fraudulent payment execution and undermining customer trust.

NHI Mgmt Group analysis

Transaction signing is now a governance control, not a UX enhancement. Banking fraud has moved beyond password theft into transaction manipulation, which means the decisive question is whether the approval event is cryptographically or visually bound to the intended payment. A control that only proves the user logged in does not stop adversary-in-the-browser fraud. For banks, the control objective is transaction integrity, and that should be treated as part of identity assurance.

Dynamic linking is the most important concept in this article because it closes the trust gap between approval and payment content. When the amount and destination are bound to the approval step, a stolen session becomes far less useful to an attacker. That makes dynamic linking especially relevant for financial organisations that face AiTM and social engineering attacks. The practitioner takeaway is simple: if the transaction can be altered after user verification, the control has not finished its job.

Phishing resistance and replay resistance solve different problems, and banks need both. Phishing resistance reduces credential capture, while replay resistance limits what an attacker can do with intercepted authentication material. That distinction matters in IAM and fraud programmes because many implementations over-index on login hardening and under-invest in post-authentication integrity. The governance lesson is to evaluate controls by what they still protect after the user session is compromised.

WYSIWYS exposes a broader identity assurance principle: the signer and the action originator must remain bound throughout the transaction. In high-value banking flows, identity proofing at login is only a starting point. If the approval device, transaction content, and verification channel are not bound together, social engineering can still defeat the process. Practitioners should treat this as a transaction governance requirement, not a niche authentication feature.

What this signals

Transaction assurance is becoming the more durable control boundary in fraud programmes. As banks adopt stronger login methods, attackers are shifting to session interception and transaction manipulation, which means the control target has moved from access to action. That shift is also relevant to NHI governance because the same principle applies whenever machine or service identities can trigger downstream financial or operational actions.

Dynamic linking creates a practical model for reducing fraud blast radius. When approval is bound to the specific amount and beneficiary, the attacker must defeat the transaction itself rather than merely the user session. For practitioners, that means aligning fraud controls, IAM policy, and device trust so they verify the same event from different angles.

A useful way to frame this is post-authentication integrity: the approval path must remain trustworthy after the identity check is complete. That concept maps well to identity programmes that already think in terms of step-up, session risk, and privilege boundaries, and it gives security teams a clearer way to prioritise controls for high-risk banking workflows.

For practitioners

• Implement transaction binding for high-risk payments Require the approval step to display and cryptographically bind the payee, amount, and transaction reference before authorisation.
• Add out-of-band verification for privileged customer actions Use a trusted device or independent verification channel for changes that can redirect funds, alter beneficiaries, or approve large transfers.
• Separate login assurance from payment assurance Measure whether MFA, passwordless login, and step-up checks actually prevent transaction tampering after session establishment.
• Test controls against AiTM and browser manipulation Simulate adversary-in-the-middle attacks and in-browser transaction rewriting to validate that the approval flow still detects altered content.
• Prioritise replay-resistant authenticators for fraud-sensitive flows Select authentication methods that minimise reusable artefacts and keep key material off general-purpose endpoints used for banking approvals.

Key takeaways

• Banking fraud now depends as much on transaction manipulation as on credential theft, which makes login-only controls insufficient.
• The most useful evidence here is the scale of the problem: phishing attacks rose 58.2% year over year, and fraud costs in financial services multiply quickly.
• Banks should prioritise transaction signing, dynamic linking, and replay resistance where the cost of a fraudulent approval is high and recovery is difficult.

Key terms

• Transaction Signing: A method of binding user approval to a specific action, amount, or destination so the approval cannot be reused for a different transaction. It is especially valuable when a valid session is not enough to prove the user intended the exact action being executed.
• What You See Is What You Sign: What You See Is What You Sign, or WYSIWYS, means the user approves exactly the transaction details that are displayed to them. It is a control pattern designed to prevent browser or message manipulation from changing the content after the customer has reviewed it.
• Adversary-in-the-Browser: Adversary-in-the-Browser is a fraud technique where malware or malicious code in the browser changes what the user sees or submits during a financial transaction. The user believes they are approving one action, while the attacker substitutes different details before the transaction completes.
• Dynamic Linking: A transaction integrity control that binds authentication to the payment amount and payee. If either changes, the authentication code is no longer valid, which helps stop substitution attacks and prevents a legitimate approval from being reused for a different transfer.

What's in the full article

OneSpan's full article covers the operational detail this post intentionally leaves for the source:

• How Digipass FX2 combines FIDO and Cronto cryptograms in specific banking workflows
• The article's explanation of WYSIWYS and dynamic linking in transaction approval
• The vendor's discussion of PSD2 and PSD3 alignment for banking authentication
• Why the device-level verification model is intended to resist AitM and AitB fraud patterns

👉 OneSpan's full post covers FIDO, Cronto cryptograms, and banking fraud scenarios in more detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of practical security programmes. It is suitable for practitioners who need to connect identity controls to broader risk, fraud, and access governance.