Fraud teams weren't the first to care about how customers behave online. Marketing, web analytics, and user-experience teams had been observing digital journeys for years, often visualizing clicks, cursor activity, and scrolling as heat maps. They wanted to know which parts of a page held visitors' attention, where they hesitated, and how quickly they moved between pages or abandoned a journey [8].

The fraud use case asked a different question of similar raw material. Marketing wanted to know: What interests this customer, and how can we improve the journey? Fraud teams wanted to know: Does this journey look human, and does it look like this customer?

For many banks, behavioral analytics started at the login page. The idea was simple: a fraudster might steal the customer's username and password, but would they enter those credentials the same way the customer would?

Early work often focused on keystroke dynamics. How long does the user hold each key? How quickly do they move from one key to the next? Do they type continuously, pause halfway through, or correct themselves? The password was something the customer knew. The rhythm of entering it became an additional signal about who might be behind the keyboard [7].

It sounds clever, and it is. But even this simple use case shows why behavioral analytics cannot be reduced to “fast equals fraud.”

Consider a legitimate customer using 1Password, RoboForm, or a browser's built-in credential manager. Instead of typing the username and password, the application fills both fields almost instantly [6]. If the detection logic assumes that instant entry means a bot or a credential-stuffing attack, good security behavior creates a fraud alert. The customer is not behaving like a fraudster. They are using a tool specifically designed to avoid weak, reused, or manually entered passwords.

This does not make typing speed useless. It means the signal needs context. Did the browser report an autofill event? Is this how the customer normally logs in? Does the rest of the session look automated? Is the device familiar? A mature system should distinguish password-manager autofill from scripted credential stuffing rather than punish both for being quick.

The same lesson applies to everything that follows: behavioral analytics does not find fraud through one unusual action. It builds confidence by combining signals and understanding why they may have changed.

Picture this: a customer logs in to ABCBank from the same phone she has used for two years. The password is correct. The device is trusted. The location is familiar. Nothing in the session looks obviously wrong.

Yet something feels different.

She normally moves quickly through the app. Today, she pauses before each step. She opens the payment screen, leaves it, returns, and pastes an account number instead of selecting a saved beneficiary. Her typing rhythm is slower. The phone barely moves in her hand.

Should the bank stop the payment?

Now reverse the situation. The same customer is standing on a crowded train, using one hand, correcting every second word while the carriage shakes. Her behavior looks unusual because the situation is unusual. Should the bank stop that payment too?

This is the promise and the problem of behavioral analytics. It can see signals that passwords, one-time passwords, and device IDs cannot. But you need to understand those signals properly. Otherwise, a useful layer of fraud defense quickly becomes another score that everyone trusts, and nobody can explain.

What Behavioral Analytics Actually Measures

We all have small habits when we use a computer or mobile phone. We do not notice most of them, but software can measure them.

In plain language, behavioral analytics analyzes how a person interacts with a digital service and how that interaction compares with their own history. Like other anomaly-detection techniques, its backbone is establishing what normal behavior looks like for a particular customer and identifying meaningful deviations from that baseline.

Population-level patterns can still help identify bots or behavior commonly associated with fraud, especially when customer history is limited. But they are supporting context. The central question is not whether the customer behaves like an average user. It is whether the customer behaves like themselves.

Behavioral analytics doesn't flag one suspicious click. It observes a sequence of small signals and asks whether the behavior fits the person, the task, and the situation.

On a keyboard, the system can observe:

• how long a key remains pressed, often called dwell time
• the time between one key and the next, often called flight time
• typing speed, rhythm, pauses, and correction patterns
• whether information is typed, pasted, or entered using autofill

With a mouse or trackpad, it can observe:

• movement speed and acceleration
• the shape and curvature of the path
• hesitation before clicking
• whether the user moves directly to a target or searches around the page

On a mobile device, the available signals become even richer:

• swipe speed, length, angle, and arc
• touch pressure and contact area, where the device exposes them
• scrolling speed and how it slows down
• how the device is tilted or held while the customer types
• small movements captured by the accelerometer and gyroscope

There is also a higher layer that is less about motor skills and more about navigation. Which field does the customer complete first? Do they use the Tab key or click between fields? Do they usually check the balance before making a payment? How often do they correct themselves? Do they paste a beneficiary account number or type it? These are representative signals, not a mandatory list: availability varies by channel, device, operating system, and implementation [4][5][9][10].

None of these signals proves identity on its own. The value comes from combining many weak signals and comparing the current session with the customer's previous behavior or with population-level patterns. A different typing speed means very little by itself. A different typing rhythm, unusual mouse movement, an unfamiliar navigation path, and repeated pasting may tell a much more interesting story.

This is also why behavioral analytics can work quietly in the background. Unlike a fingerprint scan or a one-time password, the customer does not need to stop and perform a separate authentication step. The system can continue assessing confidence throughout the session [1].

Three Different Things That Are Usually Sold as One

The terminology in this area is unnecessarily confusing. Behavioral biometrics, behavioral analytics, and device intelligence are often bundled into one product and discussed as if they answer the same question. They do not.

Behavioral Biometrics: How You Interact

Behavioral biometrics focuses on the physical and motor patterns of the person using the device: typing rhythm, mouse movement, touch gestures, swiping, and device handling.

Its core question is: Does this interaction resemble the person we have seen before?

Behavioral Analytics: What You Normally Do

Behavioral analytics is broader. It looks at how the customer normally uses the account: when they log in, which functions they use, the sequence of screens they visit, typical payment values, common beneficiaries, and the time they usually spend on different tasks.

Its core question is: Does this session resemble the customer's normal activity?

Device Intelligence: What You Are Using

Device intelligence examines the device and its environment: browser and operating system characteristics, device identifiers, emulator or jailbreak indicators, remote-access software, malware signals, IP information, and other technical attributes. I covered this layer in more detail in Device fingerprinting - how it works and where it fits in fraud detection.

Its core question is: What device and technical environment is producing this activity?

The distinction matters. A known customer can use a new device. A fraudster can use the customer's known device. The real customer can behave abnormally because they are distracted, injured, or under pressure. One green result does not make the other two questions disappear.

 Figure 1: Behavioral biometrics, behavioral analytics, and device intelligence answer three different questions.

What Behavioral Analytics Is Not

Behavioral analytics is not a replacement for authentication. It does not make passwords, passkeys, device binding, or step-up controls unnecessary. It adds confidence after or alongside those controls.

It is not transaction monitoring. A behavioral system may see that the person moves through the payment journey differently, but it does not automatically know whether the amount, beneficiary, merchant, or flow of funds is suspicious.

It is not device fingerprinting. A device can be recognized while the person using it has changed, and the same customer can behave consistently across more than one device.

It is not proof of fraud. Behavioral output is a probability, not a verdict. A mismatch can be caused by a fraudster, but also by injury, stress, travel, a new keyboard, an application redesign, accessibility software, or somebody trying to type on a moving train.

Most importantly, it is not intent detection. A system may recognize the genuine customer's hands. It cannot conclude from that fact alone that the customer understands the payment or is acting without manipulation.

Where It Fits, and Where It Does Not

The easiest way to decide whether behavioral analytics belongs in a use case is to ask a simple question: Would knowing how the user is interacting materially change the decision?

Not Relevant: There Is No Meaningful Interaction to Observe

Behavioral analytics is generally not relevant when an event arrives through a system-to-system interface, batch process, standing instruction, or other channel where no person is actively navigating, typing, touching, or making choices in the measured environment.

It is also of limited value for a new customer with no history if the design depends entirely on comparison with that individual's previous behavior. Population-level bot and fraud patterns can still help, but that is a different type of comparison and should be described honestly.

Weak Fit: The Important Signal Exists Somewhere Else

Behavioral analytics contributes little when the primary fraud evidence isn't in the digital interaction. The clearest example is an APP scam where the genuine customer makes the payment: the behavior may be completely normal because the customer is using their own device and following the usual payment journey. This is fundamentally different from social-engineering-enabled ATO, where the fraudster ultimately takes control of the session. The same limitation applies to:

• card-present fraud at a physical terminal
• merchant collusion or merchant bust-out
• first-party misuse where the genuine customer behaves normally
• invoice fraud identified through altered documents or supplier details
• money-laundering networks visible mainly through the movement of funds
• fraud involving corrupt employees or back-office process abuse

The customer may interact perfectly normally in all these cases. Transaction analytics, graph analytics, merchant monitoring, document analysis, access controls, or employee monitoring are better placed to find the risk. For laundering and coordinated fraud networks, the relationships described in From Hype to Reality - Fighting Fraud with Graph Analytics are often far more revealing than the customer's cursor movement.

Useful Supporting Signal: Behavior Adds Context but Cannot Decide

There are use cases where behavioral information helps, but only when combined with other evidence:

• New beneficiary and high-risk payments: hesitation, unusual navigation, or pasting can increase concern, but transaction value, beneficiary risk, device information, and account history still matter.
• Remote-access scams: behavioral and device signals may reveal unusual session control, but performance depends on the remote-access method and the telemetry available.
• Social-engineering indicators: hesitation, distraction, an unfamiliar journey, or signals associated with an active call may add context to a scam score. They do not measure intent and cannot prove the customer is acting under instruction.
• Mule-account monitoring: navigation and account-use patterns may enrich detection, but fund flows, counterparties, account history, and graph relationships are usually more important.
• Application fraud: automated form completion and repeated interaction patterns can help, but identity, document, device, and network evidence carries much of the decision.

Here, behavioral analytics is one instrument in the orchestra. Turning it into the conductor creates more confidence than the evidence deserves.

Its most practical contribution may be a set of features added to an existing rule or model rather than a separate alert. A payment to a new beneficiary is common. Combine it with a new device, unusual navigation, extensive hesitation, and pasted account details, and the same event deserves a different response. This is the composite principle discussed in From Hype to Reality - Fighting Fraud with Composite AI: different controls cover different blind spots.

Strong Fit: The Operator May Not Be the Customer

Behavioral analytics is strongest when the fraud problem involves a different person or a machine operating the account. Credential stuffing, scripted login attempts, account takeover (ATO) with stolen credentials, and session takeover after authentication all fit this pattern. A bot may have the correct password, but its speed, navigation, repetition, and field interactions can look very different from the customer's baseline or normal human behavior.

Social engineering can also lead to ATO. A fraudster may convince the customer or a call-center agent to disclose credentials, reset access, or change contact details. Once the fraudster becomes the operator, behavioral signals can help reveal that the person using the account has changed, even if every credential is technically valid.

This is also where continuous authentication makes sense. Instead of trusting the login forever, the bank can keep assessing the session. If confidence remains high, routine activity can continue without another challenge. If it drops during a password reset, beneficiary creation, or payment, the bank can step up authentication or intervene. Done well, behavioral analytics can reduce friction as well as fraud.

Automated account opening is a related but slightly different use case. No established customer baseline exists yet, so detection relies more on population-level bot patterns, repeated journeys, and links to device or network intelligence. That distinction should be visible in the design and in how the result is explained.

The conclusion is not that behavioral analytics is narrow. Its value depends on the attack. If the identity of the operator is uncertain, behavior can be powerful. If the real customer is acting with fraudulent intent, or if the decisive evidence sits in the transaction network, document, merchant, or internal process, behavior may be secondary or irrelevant.

Figure 2: The relevance of behavioral analytics depends on whether observing the operator materially changes the fraud decision.

Where the Hype Ends

Behavioral analytics gives a strong answer to a narrow question: Are these likely to be the customer's hands on this device right now?

That is useful, but it is not always the question the bank needs to answer.

Remote-access tools can blur who is producing the interaction. Depending on how the session is controlled and which signals are collected, some behavior may come from the fraudster, some from the customer's device, and some may be changed by the tool itself. A reliable-looking score must not be interpreted outside that technical context.

The harder boundary is a coached customer. If a fraudster is on the phone telling a genuine customer exactly what to do, the customer's password is real, the device is real, and the hands are real. Nothing has been impersonated. Behavioral analytics may observe hesitation, distraction, or an unusual journey, but it cannot assume that abnormal behavior always means coercion, nor can normal behavior prove free intent.

This distinction is important: behavioral analytics can help determine who is operating the session. It cannot, by itself, determine why they are doing it.

There are other practical limits. Behavior changes. A customer may be traveling, injured, tired, using accessibility tools, holding a baby, or simply learning a redesigned application. Research on behavioral authentication warns about profile drift and the difficulty of measuring real-world error rates [2][3]. A model trained on yesterday's behavior should not become the customer's permanent definition.

Before a model can identify a deviation, it must first establish a trusted baseline. That creates an enrollment problem: how many sessions are enough, and how do we know the person completing them is the genuine customer? If compromised sessions enter the learning period, or the model adapts too quickly during an account takeover, it can learn the fraudster's behavior as the customer's new normal. Learning windows, baseline updates, and any suspension of adaptation during high-risk sessions therefore need explicit controls [2].

Privacy and governance matter too. These systems collect detailed information about how people interact with technology. The fact that collection is passive does not make it insignificant. Fraud teams need clear retention rules, controlled access, documented purposes, and a defensible explanation of how the score affects customers.

What This Means for Your Organization

If you already use behavioral analytics, start by finding every place where its output affects a decision.

1. Separate the layers. Document which signals come from behavioral biometrics, wider account behavior, and device intelligence. Do not allow one blended score to hide three different questions.

2. Audit what a green result inherits. Check every rule, model, and workflow that treats a positive behavioral match as evidence that the activity is legitimate. Decide whether that assumption is deliberate and whether it still holds for scams involving the real customer.

3. Use confidence, not certainty. Behavioral output is probabilistic. Combine it with transaction context, device risk, account history, graph relationships, and known fraud patterns.

4. Design the response by risk. A weak behavioral mismatch during balance inquiry may justify observation. The same mismatch during a password reset or high-value payment may justify step-up authentication or intervention.

5. Measure customer impact. Track false positives across device types, accessibility needs, age groups, travel, app releases, and changes to the customer journey. A model can improve fraud detection while quietly damaging the experience for a particular group.

6. Test the limit cases. Include bots, stolen credentials, new devices, remote-access sessions, legitimate behavioral change, and coached customers in your testing. Evaluate a control against the attacks it claims to detect and the attacks it does not.

The Bottom Line

Behavioral analytics adds something genuinely valuable to fraud detection: context about the human interaction behind a digital event. It can expose bots using correct credentials, identify account takeover before money moves, and maintain confidence throughout a session without repeatedly interrupting the customer.

But it is not a truth machine.

It measures patterns and produces confidence. It can tell you whether the session looks like the customer, or not. It cannot automatically tell you that the payment is safe, that the customer is acting freely, or that another fraud control is no longer needed.

The technology moves from hype to reality when the question is precise. Use behavioral biometrics to understand the hands. Use behavioral analytics to understand the journey. Use device intelligence to understand the environment. Then combine those answers with transaction, network, and fraud context before deciding what to do.

In modern fraud prevention, recognizing the customer matters. Understanding what is happening to the customer is the harder problem.

References

[1] NIST, “Expanding Continuous Authentication with Mobile Devices”: https://www.nist.gov/publications/expanding-continuous-authentication-mobile-devices

[2] NISTIR 8334 (Draft), “Using Mobile Device Biometrics for Authenticating First Responders”: https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8334-draft.pdf

[3] Eberz et al., “Evaluating Behavioral Biometrics for Continuous Authentication: Challenges and Metrics”: https://ora.ox.ac.uk/objects/uuid:126411b1-2e76-4a00-8fdc-4c6bf5dacb90

[4] BioCatch, “Advanced Behavioral Biometrics”: https://www.biocatch.com/resources/solution-brief/advanced-behavioral-biometrics

[5] LexisNexis Risk Solutions, “BehavioSec Behavioral and Device Intelligence”: https://risk.lexisnexis.com/global/en/products/behaviosec

[6] 1Password Support, “Change where a login is suggested and filled”: https://support.1password.com/autofill-behavior/

[7] Choi et al., “Benchmark Keystroke Biometrics Accuracy From High-Stakes Writing Tasks”: https://doi.org/10.1002/ets2.12326

[8] Arroyo et al., “Building a Better Mousetrap: Compressing Mouse Cursor Activity for Web Analytics”: https://doi.org/10.1016/j.ipm.2014.10.005

[9] Sultana et al., “The Utility of Behavioral Biometrics in User Authentication and Demographic Characteristic Detection: A Scoping Review”: https://pmc.ncbi.nlm.nih.gov/articles/PMC10851515/

[10] Frank et al., “Touchalytics: On the Applicability of Touchscreen Input as a Behavioral Biometric for Continuous Authentication”: https://arxiv.org/abs/1207.6231