Risk-based authentication (RBA), also called adaptive authentication, is an approach that evaluates the risk of each authentication attempt in real time and adjusts the requirements accordingly, letting low-risk users through smoothly while challenging high-risk ones. Instead of treating every login identically, it matches the level of friction to the level of risk.

RBA is how modern identity resolves the oldest tension in the field: security versus experience. Most logins are legitimate and low-risk; forcing all of them through heavy authentication punishes good customers to catch a rare attacker. RBA flips that.

The signals behind the decision

An RBA engine scores each attempt using a range of signals:

• Device: is this a known, trusted device, or a brand-new one? Any signs of an emulator or tampering?
• Location and network, does the location fit the user’s pattern? Is the connection coming through anonymizing infrastructure?
• Behavior: does the typing cadence, navigation, or interaction match how this user normally behaves (behavioral biometrics)?
• Velocity and context: impossible travel, unusual timing, or a sudden change in activity.

The engine combines these into a risk score, which drives the outcome.

From score to action

Based on the score, the system chooses a response, commonly framed as a spectrum from trust to deny. A trusted, low-risk login proceeds invisibly. A moderately risky one triggers step-up authentication (an extra factor). A high-risk one is blocked or sent for review. In a platform that fuses identity and fraud, this is where the fraud engine’s judgment (Trust, Allow, Challenge, or Deny) directly drives the authentication journey through orchestration.

Why RBA matters for financial services

For banks and fintechs, RBA is the mechanism that keeps fraud out without smothering conversion. It concentrates friction on the risky minority, so the vast majority of customers get a fast experience while attackers meet escalating resistance. It also adapts continuously, as attack patterns shift, the signals and scoring adjust, rather than relying on static rules that fraudsters quickly learn to evade.

From risk score to outcome: Trust, Allow, Challenge, Deny

A useful way to picture RBA’s output is a four-way decision. A very low-risk, trusted session earns Trust. It proceeds with no friction at all. A normal session gets Allow. A session with elevated risk gets Challenge, a step-up that asks for more proof. And a session that looks clearly malicious gets Deny, blocked or routed to review. This is exactly the model a fused identity-and-fraud engine uses: it weighs behavioral, device, and network signals to place each attempt into one of those buckets, and orchestration then triggers the matching journey automatically. The value is precision, you’re not choosing one friction level for everyone, you’re matching the response to the specific risk, which lifts both security and conversion at once.

Frequently asked questions

What is the difference between risk-based and adaptive authentication?

The terms are used interchangeably, both adjust authentication to the assessed risk of each attempt.

What signals does RBA use?

Device, location, network, behavioral biometrics, velocity, and contextual anomalies.

How does RBA reduce friction?

It lets low-risk logins proceed smoothly and reserves extra authentication for risky sessions.

What are the possible outcomes of a risk decision?

Commonly Trust, Allow, Challenge, or Deny, from frictionless access through step-up to a block.

Does RBA replace MFA?

No. It decides when to require stronger authentication like MFA, rather than applying it to everyone.

Related: Step-Up Authentication · Adaptive Authentication · Behavioral Biometrics · Device Fingerprinting · Identity Orchestration · Risk Scoring