Financial institutions once treated authentication as a gate at the beginning of a digital interaction. A customer proved identity at login, and the resulting session was trusted until logout or expiration. That model assumes risk is highest at the entrance and remains relatively stable afterward. Fraud no longer follows that pattern. Attackers may arrive with stolen credentials, manipulate customers into approving a challenge, hijack an authenticated session, change account details after login or move money without warning.
At the same time, legitimate customers expect routine digital banking tasks to be quick. A fixed policy that challenges every login or transaction treats a balance check from a familiar device much like a new-payee wire transfer from an unfamiliar environment. The institution either introduces more friction than the risk warrants or applies too little protection when the consequences are high.
Authentication should rise with the risk of the interaction. The practical objective is well-timed multi-factor authentication (MFA): Routine activity should proceed without an added challenge, while stronger proof should be required when identity confidence falls, the potential consequence rises or both occur together. Adaptive authentication supports that objective by turning signals from the user, device, session and requested action into a proportionate decision to allow, challenge or stop the activity.
Authentication Risk Now Develops Throughout the Session
Many institutions still concentrate authentication controls at login even though a successful login does not settle every question that follows. A customer may sign in normally, then update a phone number, enroll a new device, add a payee and initiate a transfer. Each event may be legitimate in isolation. Together, especially when they occur quickly or diverge from the customer's history, they can describe an account takeover in progress.
Blanket MFA does not solve that problem well. Frequent challenges interrupt low-risk activity, increase abandonment and generate support calls, particularly when customers cannot access a registered factor. They can also condition users to approve prompts automatically, weakening the value of a challenge when one truly matters. A login-only model creates the opposite problem by giving too much weight to a decision made at the start of the session. Both approaches separate authentication from the changing risk of the activity.
A stronger model keeps evaluating the interaction after access is granted. It recognizes that trust can strengthen as familiar patterns accumulate or decline when the device, behavior or requested action changes. Step-up authentication then becomes one response within a broader control strategy, rather than a universal checkpoint.
Evaluate Identity Confidence and Potential Consequence Together
A useful framework begins with two questions. First, how confident is the institution that the person controlling the session is the legitimate customer? Second, what could happen if the requested action is fraudulent? Identity confidence reflects signals such as device familiarity, location, network context, behavior and recent account history. Potential consequence reflects the value, reversibility and sensitivity of the action.
These dimensions should influence each other. A familiar customer checking a balance from a recognized device presents high identity confidence and limited immediate consequence, so the normal flow may be appropriate. A familiar customer making an unusually large real-time payment presents higher consequence even if the session otherwise looks normal, which can justify transaction confirmation. A password reset from a new device in an unexpected location creates low confidence before any money moves, because control of the account itself is at stake.
This approach reflects the broader direction of NIST guidance on risk-based authentication, which identifies user, system, environmental and behavioral attributes as inputs to an authentication decision. FFIEC guidance likewise emphasizes periodic risk assessment and layered controls for financial institutions. The practical implication is that MFA should be tied to the institution's risk model, rather than deployed as an isolated control with the same trigger everywhere.
Signals That Should Change the Authentication Decision
No single indicator provides a reliable verdict in every case. Customers replace phones, travel, use privacy tools and change their routines. A risk engine should weigh the strength of each signal, consider how several signals combine and account for the consequence of the requested action. A new device may deserve observation during a low-risk balance inquiry. The same device becomes more concerning when it appears in a new location, changes profile information and immediately initiates a high-value payment.
New devices and location anomalies
A first-seen device, browser or application instance should lower confidence because the institution has less history to evaluate. Device reputation, operating system changes, network attributes and signs of device compromise can add context. Location anomalies also matter, particularly when travel speed is implausible or the location conflicts with established patterns. Yet device and location changes are common in legitimate use, so they should influence the decision without serving as automatic proof of fraud.
Unusual behavior and suspicious sessions
Behavioral and session signals show whether the interaction still resembles the customer's normal activity. Typing cadence, mouse or touchscreen patterns, navigation order, session timing and the speed of actions can reveal meaningful deviations. Repeated failed attempts, abrupt movement to sensitive functions, unusual copy-and-paste behavior or a sequence that resembles automation may also raise risk. These signals become more valuable when evaluated continuously because they can detect a change after valid credentials and MFA have already been accepted.
High-risk transactions
The transaction itself should affect the authentication threshold. Amount, destination, payment rail, velocity, timing and prior history all shape potential consequence. A payment to a known recipient within the customer's normal range may proceed without interruption. A first payment to a new recipient, a rapid series of transfers or an unusually large real-time payment should require greater confidence because recovery may be difficult once funds move.
Account profile and recovery
Profile changes deserve special attention because they can prepare the account for later fraud. Updating a phone number or email address, resetting a password, enrolling a device, changing notification preferences or raising transaction limits can let an attacker establish persistence and redirect warnings. Authentication should occur before a sensitive change takes effect, using a factor or trusted channel that the change has not just replaced. Institutions may also apply a delay, added monitoring or limits when several recovery and payment events occur close together.
Match the Response to the Level and Type of Risk
Once the institution has evaluated identity confidence and potential consequence, the response should be proportionate. The choice is broader than whether to present MFA. Most interactions should fall into one of three paths, each supported by clear policy and a defined customer experience.
| Decision | When it fits | Operational response |
|---|---|---|
| Allow | Identity confidence is high, behavior is consistent and the action carries low or expected consequence. | Continue the normal flow while passive risk evaluation remains active. Avoid adding a visible challenge simply because one is technically available. |
| Step up | Uncertainty is meaningful but can be resolved, or the action is sensitive enough to require stronger proof. | Use a factor suited to the channel and bind approval to the action when possible. For a payment, show the customer the amount and destination being approved. |
| Stop or hold | Signals indicate likely compromise, or the available challenge may also be controlled by the attacker. | Block, delay or route the action for review. Contact the customer through an established trusted channel instead of repeatedly presenting the same challenge. |
A step-up challenge should address the uncertainty that triggered it. If the institution needs to confirm possession of a trusted device, a push or software token may be appropriate. If the risk centers on a payment, the customer should approve the specific transaction rather than a generic login prompt. Repeating a factor that may already be compromised adds inconvenience without necessarily adding confidence.
The stop or hold path is equally important. Some sessions should not receive another opportunity to authenticate, particularly when there are signs of push fatigue, recent replacement of a trusted contact method or a device associated with known malicious activity. In those cases, protecting the customer may require a temporary hold, manual review or verified outreach through a previously established channel.
Build Policy Around Customer Outcomes
Adaptive authentication requires joint ownership. Identity teams understand authenticators and access policy. Fraud teams understand attack patterns, loss exposure and the way signals combine. Digital product teams understand where friction causes customers to abandon a task or seek support. These teams should define the risk taxonomy, thresholds, customer messages and recovery paths together so that a security decision does not create an avoidable product or operational failure.
Policies should begin with the institution's highest-risk journeys, such as account recovery, contact changes, new device enrollment, payee creation and high-value payments. Teams can then map the signals available at each point, decide which combinations change the decision and test the logic against historical activity. A period of observation before enforcement can reveal how many legitimate customers would be challenged or stopped and whether certain segments are affected disproportionately.
Measurement should extend beyond the number of MFA challenges completed. Institutions need to monitor challenge rates, completion and abandonment, false declines, account takeover, fraud losses, support volume, recovery success and task completion time. Teams should review these measures by journey and customer segment. A falling fraud rate can hide excessive friction, while a high completion rate can hide challenges that are too easy for attackers to satisfy.
Business continuity also belongs in the policy. Customers lose phones, travel without cellular service and encounter accessibility barriers. Authentication services and delivery channels can fail. Each high-risk journey needs an approved fallback that preserves sufficient assurance, along with a clear decision about which low-risk activities may continue during an outage and which sensitive actions must wait. This prevents the institution from choosing between unrestricted access and a complete digital shutdown when a factor is unavailable.
How 360 Adaptive Authentication Puts the Framework Into Practice
360 Fraud Protection by AppGate's 360 Adaptive Authentication provides a developer-first framework for embedding authentication into mobile applications, web experiences and digital payment workflows through SDKs and APIs. It combines behavioral biometrics, device intelligence and contextual analysis so institutions can evaluate risk throughout an interaction and apply stronger authentication when the activity warrants it.
The platform supports push authentication, QR codes, mobile software tokens and out-of-band one-time passcodes (OTPs). That range lets teams select a method that fits the channel, the customer and the action. A low-risk interaction can continue with minimal interruption, while a sensitive transaction or suspicious session can trigger immediate verification. Cross-channel support also keeps policy consistent as customers move among mobile, web and payment experiences.
Adaptive authentication connects the institution's risk decisions to the control that acts on them. Fraud, identity and digital product teams can use the same framework to decide which interactions should remain seamless, which require additional proof and which should be stopped before loss occurs.
Authentication Policy Should Change as Risk Changes
The effectiveness of MFA depends on when it appears, what it proves and what happens if the risk remains unresolved. Institutions that challenge every customer create friction without making every interaction safer. Institutions that authenticate only at login miss the account and transaction events where risk can change most sharply. A risk-based approach closes that gap by evaluating identity confidence alongside the consequence of the action and adjusting the response as the session develops.
This approach produces a more disciplined use of authentication. Familiar, low-risk activity stays easy, uncertain or consequential activity receives stronger proof and likely fraud is stopped instead of pushed through another routine prompt.
Explore 360 Adaptive Authentication to see how 360 Fraud Protection by AppGate applies the right authentication control at the right moment.