Skip to content
All insights AI for fraud & financial crime

Behavioural biometrics for continuous authentication

A password proves who logged in, not who is typing now. Here is how we use behavioural biometrics for continuous, privacy-aware authentication.

5 min read #fraud#authentication#session-security
Financial services professionals working through an AI initiative

A password proves who logged in. It says nothing about who is holding the keyboard ten minutes later, once the session cookie has been stolen or a remote-access tool has taken over the screen. Behavioural biometrics closes that gap by scoring how a person types and moves through a flow, continuously, so the system reacts when the operator changes mid-session and not only at the door.

The reason this matters is the shape of modern account takeover. The credential is rarely the weak link anymore; the attacker usually already has it. What they cannot easily reproduce is the muscle memory of the genuine user: the rhythm between keystrokes, and the order in which someone tabs through a form they fill in twenty times a day. Those signals are hard to phish and hard to buy on a forum, and they persist for the whole session rather than the first second.

What the signals actually are

The raw material is timing and motion, sampled from events the browser or app already emits. None of it is the content of what the user types.

  • Keystroke dynamics: dwell time (how long a key is held) and flight time (the gap between releasing one key and pressing the next). Digraph and trigraph latencies for common letter pairs are stable per person and shift when someone else takes over.
  • Pointer and touch behaviour: velocity and acceleration curves, click-to-target overshoot, scroll cadence, and on mobile the pressure and swipe geometry.
  • Interaction structure: navigation order through a known flow, hesitation before high-value fields, copy-paste patterns, and the tempo of a repeated task a real operator has automated in their hands.
  • Device and context, kept separate: coarse platform, timezone, network. These are supporting features, not the core signal, and we keep their lineage distinct so a device change alone does not masquerade as a behavioural one.

A point worth making plainly: content is not needed and should not be collected. You capture that a key event happened and when, not which character it was. This keeps the feature set defensible under Article 9 of the GDPR and keeps the audit trail clean when a regulator asks what you stored.

Turning signals into a live decision

This is a per-user verification problem. During enrolment you build a profile from a person’s genuine sessions, then at inference you score how far the current session sits from that profile. The question is whether the session matches this account’s own history, not whether it looks unusual against the wider population. A rising anomaly score across a window is the signal; one odd keystroke means nothing on its own.

The engineering hazards here are the same ones that quietly wreck any behavioural model:

  • Leakage and point-in-time correctness. Enrolment sessions must be confirmed-genuine as of the moment you train, not relabelled later because the account turned out to be fraudulent. If a takeover session leaks into the enrolment set, the profile learns the attacker. Version the profile and keep lineage on every session that fed it.
  • Cold start. New users have no profile, so early sessions score against a population baseline and stay in a lower-trust state. Be explicit that the false-positive budget is different in this phase, because friction on a genuine new customer is expensive.
  • Drift. People’s typing changes with a new keyboard, an injury, a switch from desktop to laptop. The profile has to adapt without adapting to an attacker, which means gradual updates gated on other trust signals and a hold-out eval set that tracks genuine-user rejection over time.
  • Concept boundaries between users who share a device. Family accounts, shared workstations at a branch, delegated access. Entity resolution has to decide whether two behavioural fingerprints are two people or one person on two machines.

Latency is a real constraint. A continuous score that arrives thirty seconds after the fraudulent transfer is a forensic record, not a control. The scoring path runs on the session’s event stream and produces an updated score every few interactions, which is what lets the decision layer step in before straight-through processing releases a payment.

Deciding what to do with a falling score

A score on its own does nothing. The value is in the response ladder you attach to it, tuned to a false-positive budget the business actually agreed to.

  • Low anomaly: do nothing, log the score for the audit trail and for later evaluation.
  • Rising anomaly on a low-value action: increase monitoring, hold the session in a state where high-value actions require re-verification.
  • High anomaly on a high-value action: step up. Re-prompt for a factor, delay the transaction, or route it to review rather than blocking outright, because a false block during quarter-end on a genuine treasury user is its own incident.
  • Sustained high anomaly with corroborating signals: terminate the session and force re-authentication.

Corroboration is the discipline that keeps this from being a nuisance generator. A behavioural anomaly on its own is weak evidence. The same anomaly alongside a new device, an impossible-travel jump, or a beneficiary added minutes earlier is a different story, and the fusion logic should be explicit about which combinations escalate. Keep the reason codes legible: when a session is stepped up or killed, the record should say which features moved and by how much, because the customer will call, the analyst will investigate, and eventually someone in compliance will ask you to explain the decision.

The honest limit of the technique is that it is probabilistic and it degrades. Profiles go stale, attackers who sit and observe can mimic tempo, and remote-access fraud where the genuine user is coached into typing produces genuine behavioural signals attached to a fraudulent intent. Behavioural biometrics narrows the window an attacker operates in and makes silent takeover expensive. It does not close the window, and any deployment that is sold as closing it will fail the first time a coached-transfer case lands with a clean behavioural score.

FAQ

Is behavioural biometrics data subject to GDPR as biometric data?

Keystroke and pointer timing used to uniquely identify a person falls under Article 9 special-category processing, so you need a lawful basis and usually a DPIA. Storing derived timing features and comparison scores rather than raw keystrokes narrows the exposure, but it does not remove the classification.

How much data do you need before the model can score a session?

Enough enrolment to build a stable per-user profile, typically a handful of genuine sessions. Until then the session scores against a population baseline, and you keep the account in a lower-trust state that leans on step-up rather than silent decisions.

Does this replace multi-factor authentication?

No. It sits behind the login as a second, always-on layer that watches the session after MFA has already passed, which is exactly the window a stolen-cookie or remote-access attack lives in.

Working on something similar?

Tell us about your data and the workflow around it, and we will give you a straight read.

Book a 30-min intro call