TL;DR: Transaction fraud is rising fast, with phishing attacks up 58.2% year over year and financial services losses averaging $4.61 for every $1 lost to fraud, according to OneSpan and LexisNexis research. The real control issue is that transaction verification must resist both credential theft and message manipulation, not just authenticate a user.
At a glance
What this is: OneSpan argues that banks need phishing-resistant transaction signing because credential theft alone no longer explains modern fraud, which also includes message manipulation and adversary-in-the-middle attacks.
Why it matters: For IAM, fraud and digital banking teams, the control question is no longer just whether a customer is authenticated, but whether the approved transaction content is still intact at the point of signing.
Context
Transaction signing is the control layer that binds approval to the exact transaction data being authorised. In banking, that matters because attackers do not always need to break authentication; they can instead intercept, alter or replay transaction details after a customer has signed in. The primary governance gap is that many fraud controls still assume identity proof at login is enough.
The article’s focus is clearly relevant to identity and transaction governance because it sits at the intersection of customer authentication, transaction integrity and social engineering resistance. That makes it more than a banking UX discussion: it is about whether a financial institution can prove that the signer, the account action and the message approved are the same thing.
Key questions
Q: What fails when transaction signing is not tied to the exact payment details?
A: The control fails because the customer may authenticate successfully while approving altered data. If the amount, destination or reference can change after display, the bank loses assurance that the signed transaction is the same one the customer intended. That creates a gap between identity proof and transaction integrity, which adversary-in-the-middle fraud can exploit.
Q: When should banks prioritise transaction signing over stronger login controls?
A: Banks should prioritise transaction signing whenever the main risk is payment manipulation, beneficiary redirection or session interception rather than simple account access. Stronger login controls still matter, but they do not stop an attacker who already sits inside the transaction flow. Signing becomes the more important control when the fraud objective is to alter what gets authorised.
Q: What are the signs that transaction approval controls are failing?
A: Common signs include fraud that occurs after successful login, customer complaints that approved details do not match what later executed, and repeated reliance on OTPs even where phishing and replay risk are high. If the approval journey cannot show a clear linkage between what was displayed and what was signed, the control is weak.
Q: How should security teams balance customer experience and phishing resistance in banking?
A: They should remove avoidable friction from low-risk steps while adding strong verification where money or account changes are involved. The goal is not to make every interaction harder, but to concentrate friction at the point where transaction integrity matters most. That gives banks a better balance between usability, fraud resistance and regulatory assurance.
Technical breakdown
Why transaction signing is different from login authentication
Login authentication proves that a user or customer reached the session. Transaction signing proves that a specific payment or transfer payload was approved, and that the payload has not changed between display and authorisation. That difference matters because phishing and adversary-in-the-middle attacks often succeed after the session is established, when the attacker can manipulate the transaction content rather than the login event. WYSIWYS, or what you see is what you sign, exists to close that gap by binding the human decision to the exact transaction state.
Practical implication: Banks should treat transaction approval as a separate control objective from customer authentication.
How phishing-resistant authenticators reduce transaction fraud
Phishing-resistant authenticators combine strong cryptographic proof with a user flow that does not depend on reusable secrets. In this article’s framing, FIDO reduces credential replay risk, while visual cryptogram-based signing helps the customer confirm transaction details on a trusted device. That matters because attackers who steal passwords or one-time passwords can still be blocked if the approval mechanism requires possession of a bound authenticator plus confirmation of the transaction content. The security gain comes from making the transaction itself part of the trust decision, not just the session.
Practical implication: Use phishing-resistant authenticators where transaction integrity matters, especially for high-value or high-risk banking actions.
Why adversary-in-the-middle attacks target transaction content
Adversary-in-the-middle attacks sit between the customer and the bank’s service to intercept credentials, session data or transaction instructions. The attacker’s objective is not always immediate account takeover; in many cases it is to alter payment details, steal funds, or redirect an authorised transaction before final confirmation. This is why replay resistance and dynamic linking matter. If the approval mechanism is not cryptographically tied to the exact amount, destination and transaction metadata, an attacker can change what the user thinks they signed without breaking the apparent login flow.
Practical implication: Banks need controls that detect or prevent transaction tampering after authentication, not just before it.
Threat narrative
Attacker objective: The attacker wants to authorise a fraudulent transaction while making the approval appear legitimate to both the customer and the bank.
- Entry begins with phishing, smishing or other social engineering that tricks the customer into revealing credentials or interacting with a fake banking session.
- Credential or session abuse follows when an adversary-in-the-middle position lets the attacker capture login data or alter transaction details in transit.
- Impact occurs when the victim signs an altered payment or transfer, allowing fraud, fund diversion or customer trust loss.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Transaction integrity has become the real banking identity control: authentication no longer provides enough assurance if the transaction payload can still be modified after login. Banks now need proof that the approved action is the same action that reaches execution. That makes signing controls part of identity governance, not just fraud tooling. Practitioners should reframe approval as an integrity control, not a session extension.
Phishing resistance matters because credentials are only one attack path: the article correctly shows that OTP theft, smishing and session interception remain practical fraud routes. The more important governance lesson is that banks must stop relying on any control that assumes a signed-in user is automatically safe to trust for downstream payment approval. This is a classic example of authentication success masking transaction compromise. Teams should evaluate whether their approval stack still assumes the user interface is trustworthy after the session starts.
WYSIWYS is the named control concept banks should sharpen: what you see is what you sign is the minimum bar for meaningful transaction verification in digital banking. Without it, the bank cannot reliably prove that the signer reviewed the true payee, amount and transaction context. That is especially relevant where customer experience pressure encourages shorter flows and fewer checks. Practitioners should preserve display integrity at the point of approval, not only improve login security.
PSD2 and PSD3 pressure the market toward stronger transaction binding: regulation is increasingly aligned with the idea that authorisation must be tied to specific transaction attributes. That does not remove the operational challenge, because banks still need controls that work across retail, commercial and wealth channels without degrading the customer journey. The governance implication is clear: transaction signing is becoming a baseline control expectation, not a niche enhancement. Practitioners should map their approval flows to explicit regulatory and assurance requirements.
NHI and workload identity lessons still apply here: once trust is placed in a signing device or service, lifecycle governance and cryptographic binding matter. The article is about human banking customers, but the control principle is the same one that governs machine credentials: the approval mechanism must be bound to the exact action and must resist replay or tampering. Identity teams should use that parallel to tighten transaction assurance models across both human and non-human pathways.
From our research library:
- Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.
What this signals
WYSIWYS is becoming the governance hinge for digital banking: banks that cannot bind approval to the exact transaction content are still leaving room for post-login manipulation. That is a control design problem, not just an authentication problem, and it changes how teams should evaluate payment journeys.
The practical signal for identity and fraud teams is that passwordless or phishing-resistant login alone is no longer enough. Approval controls must prove that the signer and the final transaction are identical at the point of authorisation, or the bank remains exposed to adversary-in-the-middle fraud.
For practitioners
- Strengthen transaction-level verification Separate login authentication from transaction approval so the bank confirms the exact amount, destination and context at signing time, not only at session start.
- Adopt phishing-resistant authenticators Prioritise authenticators that reduce replay risk and resist credential theft for customer flows that can move money or change beneficiary details.
- Bind approval to displayed transaction data Use dynamic linking or WYSIWYS-style display controls so the signed payload cannot differ from the data the customer reviewed on screen.
- Review fraud controls for AiTM resistance Test whether your current payment journey still works if an attacker intercepts the session and tries to alter transaction instructions before confirmation.
Key takeaways
- Transaction fraud can succeed even when login security holds, because attackers may alter the payment details after authentication.
- The article’s core control idea is that approval must bind the signer to the exact transaction content, not just to the session.
- Banks that want to reduce fraud without harming usability should concentrate stronger verification at the point of transaction authorisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Phishing-resistant signing addresses insecure authentication paths that still allow transaction abuse. |
| NHI-07 — Long-Lived Secrets | OTP and reusable credentials remain vulnerable when transaction approval still depends on them. | |
| Recommendation — Use NHI-04 to replace reusable approval secrets with phishing-resistant transaction verification. Reduce reliance on long-lived approval secrets and bind authorisation to short-lived transaction state. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle governs the credential mechanisms used in phishing-resistant customer flows. |
| Recommendation — Apply IA-5 to manage customer authenticators and phase out weaker approval methods. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The fraud pattern combines credential theft with movement into the transaction flow. |
| Recommendation — Map phishing and AiTM activity to TA0006 and TA0008 when analysing banking fraud paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Transaction signing is about ensuring the right action is authorised, not just the right user logged in. |
| Recommendation — Apply PR.AA-05 to keep transaction authorisation tied to the correct entitlement and action. | ||
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-middle Attack: An adversary-in-the-middle attack intercepts and relays authentication in real time between the user and the legitimate service. It is especially dangerous for OTPs because the attacker can capture the code while it is still valid and immediately use it to complete login.
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security and fraud risks that emerge when trust has to be proven at runtime.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org