Banks should reduce phishing risk by separating login from transaction approval and making the approval step carry transaction context. Use stronger authentication for access, then require a second channel or device confirmation that shows the recipient, amount, and destination. That way, a stolen password or replayed session is not enough to move money.
Why This Matters for Security Teams
Phishing risk in online banking is not just a user awareness problem. It is an authentication and transaction integrity problem. If a customer can be tricked into approving a payment without seeing the true recipient, amount, and destination, then a stolen password, session token, or OTP can be enough to trigger loss. The control objective is to make the approval step bind to the specific transaction, not just to the identity of the person who is logged in. That aligns with the outcome focus of the NIST Cybersecurity Framework 2.0, which pushes organisations to reduce identity-driven risk through stronger protection and verification.
Banks often overestimate the value of generic MFA when the real issue is transaction manipulation. A phishing kit can relay credentials, intercept one-time codes, or exploit a live session if the approval flow does not present clear transaction details. The security team’s job is to ensure the customer is not simply proving presence, but confirming intent. In practice, many security teams encounter fraud only after a customer has already authorised the wrong payee, rather than through intentional transaction confirmation design.
How It Works in Practice
The most effective pattern is to separate access from approval and make approval data-rich. First, the customer authenticates to enter the banking session. Then, when a transfer or payment is initiated, the bank requires a second confirmation step that displays the critical transaction fields in a way the customer can verify. This can be a mobile app prompt, device-bound approval, or secure out-of-band confirmation, but the key is that the approval channel must be independent enough that a phished web session cannot silently alter the payment.
Operationally, this means banks should design controls around three layers:
- Strong customer authentication for login, with phishing-resistant methods where possible.
- Transaction signing or confirmation that includes amount, payee, account destination, and timing.
- Risk-based step-up controls for unusual payees, device changes, or high-value transfers.
Control selection should also reflect the security baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls tied to authenticators, session integrity, and transaction logging. Banks should log approval events with enough detail to reconstruct what the customer saw and what was actually submitted, because fraud investigations often depend on that evidence. If mobile push approval is used, it should be hardened against notification fatigue and prompt bombing by enforcing clear transaction context and rate limits. If a browser session can approve a payment without a trusted second factor or transaction binding, the control is too weak for modern phishing threats. These controls tend to break down in high-friction legacy environments where core banking channels, customer devices, and fraud engines cannot exchange transaction context in real time.
Common Variations and Edge Cases
Tighter transaction confirmation often increases customer friction and support overhead, so organisations have to balance fraud reduction against abandonment rates and accessibility. That tradeoff is especially important for vulnerable customers, high-volume retail payments, and jurisdictions with strong consumer protection expectations. Best practice is evolving, but current guidance suggests that the highest-risk transactions deserve the strongest confirmation, while low-risk activity can use lighter controls backed by monitoring and behavioural signals.
There is no universal standard for this yet, so banks need to adapt the model to product type and threat profile. For example, card payments, account-to-account transfers, and new payee setup may require different levels of assurance. Where step-up authentication is used, it should not be the same factor already exposed to the phishing channel. Banks should also treat customer education as a supporting control, not the primary defence, because training does not prevent real-time phishing or session hijacking. The most resilient designs make transaction approval understandable, hard to tamper with, and difficult to reuse outside the exact payment the customer intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Phishing-resistant access and transaction verification reduce identity-driven fraud risk. |
| NIST SP 800-53 Rev 5 | IA-2 | Strong authenticator management is central to stopping stolen credentials from enabling transfers. |
Strengthen authentication and verification so access alone cannot authorise a bank transfer.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
