Notifications
Clear all
Topic starter
01/08/2026 8:55 pm
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.
NHIMG editorial — based on content published by OneSpan: The phishing-resistant future of banking security
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read OneSpan's article on phishing-resistant transaction verification for banking →
Transaction signing for banks: are your fraud controls keeping up?
Explore further
01/08/2026 9:03 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Phishing-resistant transaction signing is becoming core banking control
