How should banks implement customer IAM so authentication and authorization both reduce fraud risk without creating unnecessary friction?

Why Customer IAM Must Balance Fraud Reduction and Friction

Customer IAM in banking is not just about proving who signed in. It is about reducing account takeover, unauthorized transfers, and profile abuse without making legitimate customers abandon key journeys. Strong authentication helps stop impostors, but authorization is what limits damage after login. Banks often get this wrong by treating login as the main control and sensitive actions as an afterthought. Mature programs align identity checks to the risk of the action, not just the session.

That matters because fraud is rarely a single-step event. Attackers reuse stolen passwords, hijacked devices, social engineering, and session abuse to move from access to monetization. NHI Management Group’s 2024 Non-Human Identity Security Report shows that 88.5% of organisations say their non-human IAM practices lag behind or are merely on par with human IAM, a useful signal that many identity programs still over-rely on static controls. In banking, the same pattern shows up when controls are not contextual.

The practical goal is to verify the customer once, then continuously decide what that customer can do at that moment. In practice, many security teams discover weak authorization only after a fraudulent transfer or account change has already been approved.

How Banks Put Layered Authentication and Authorization Into Practice

Effective customer IAM starts with stronger authentication for sign-in, but it does not end there. Banks should apply step-up controls only when the requested action increases risk. A balance inquiry should not trigger the same friction as adding a new payee, changing contact details, or initiating a high-value transfer. That is the core of risk-based customer IAM: verify the session, then apply tighter authorization checks where fraud impact is highest.

Current guidance suggests combining multiple signals rather than relying on one factor. Passkeys can reduce phishing exposure, MFA can raise the bar for account access, and adaptive checks can use device reputation, location anomalies, velocity, and behavioural signals to decide when to step up. For privileged customer actions, the bank should require fresh assurance, not just an old login token. This is where authorization becomes a fraud control, not just a policy lookup.

For customers, this works best when the journey is short and predictable. For the bank, it means separating identity proofing, authentication, session management, and transaction authorization into different decisions.

• Use passkeys or phishing-resistant MFA for initial authentication where supported.
• Apply step-up checks only for sensitive actions, not every interaction.
• Bind sessions to device and context signals to reduce token replay.
• Authorize each high-risk transaction with policy rules based on amount, beneficiary, and risk score.
• Use real-time fraud signals to revoke or challenge sessions when behaviour changes.

Standards such as NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce this layered approach by tying identity and access controls to risk management, monitoring, and least privilege. When banks implement this well, customers see fewer unnecessary prompts while fraud teams get stronger control over high-value actions. These controls tend to break down in legacy core banking and omnichannel environments because session state, device context, and authorization rules are often fragmented across systems.

Where the Model Breaks Down in Real Banking Journeys

Tighter customer authentication often increases drop-off risk, so banks have to balance fraud reduction against completion rates and support burden. That tradeoff becomes most visible in high-friction scenarios such as password resets, device changes, card reissuance, and first-time payee setup. Best practice is evolving, but there is no universal standard for exactly how much friction is acceptable because customer base, product mix, and fraud profile all matter.

One common mistake is overusing MFA as a universal answer. MFA helps, but it is not enough if an attacker already controls the session or can socially engineer a step-up event. Another gap is overtrusting low-risk actions after initial login, even when the context changes mid-session. A bank may authenticate a customer on a familiar device, then allow a risky transfer after the device, geolocation, or beneficiary pattern changes. That is why authorization must stay dynamic.

Banking teams should also watch for populations where stronger controls are harder to deploy, including older devices, shared family access, and accessibility-sensitive workflows. In those cases, risk-based policy should reduce friction without lowering protection. The practical lesson is that identity design should follow fraud scenarios, not just compliance checkboxes. In many banks, the weakest point is not the login screen but the moment a legitimate session is asked to do something abnormal.

Related resources from NHI Mgmt Group

• How should organisations implement two-factor authentication in high-risk digital services without creating unnecessary user friction?
• How should payment organisations implement strong customer authentication without creating unnecessary checkout friction?
• How should organisations implement online passport verification without creating excessive customer friction?
• How should mobility platforms implement biometric authentication without creating unnecessary friction?