Behavioural-biometrics session windows and transaction boundaries

1. What a behavioural-biometrics score is

Behavioural biometrics, evaluated under ISO/IEC 19989-1 [2], sit outside NIST SP 800-63B Rev. 3’s [1] formal authenticator taxonomy — 800-63B does not recognise biometrics as a stand-alone authenticator and treats behavioural signals as continuous-risk inputs rather than a discrete authenticator type. The EBA’s June 2019 Opinion on the elements of strong customer authentication under PSD2 sets the regulatory conditions under which behavioural patterns may contribute to inherence. The output is a score derived from observed user behaviour over a window of interaction. Vendors in the category — among them BioCatch, Callsign, BehavioSec, TypingDNA — collect features such as keystroke inter-key timing, mouse trajectory curvature, gesture rhythm, navigation cadence, and device-handling micro-motion. The features are aggregated across a session and produce a score, a probability, or a delta from a learned per-user baseline. Adjacent fraud-analytics platforms (Featurespace, NICE Actimize, Outseer) consume some of the same session features but combine them with transaction history rather than producing a stand-alone behavioural score.

The data model is statistical, not cryptographic. The system says “this session, on this device, looks like the user we have learned — or it does not.” It does not say “this specific transaction was signed by the user.”

2. The session is the unit of observation

The window over which a behavioural score is meaningful is the window across which features were collected. In practice this is a session: bounded at one end by app launch, login, or wakeup; bounded at the other end by logout, idle timeout, or app background beyond a configured threshold. Vendor documentation typically states a session-confidence value that decays with idle time and recovers with new observations. The value is meaningful for the session as a whole.

A single payment event sits inside this session as a point. Its relation to the session score is contextual: the score is the same whether the user enters one transaction or twenty during the window, whether the transaction is for ten or ten thousand units of local currency, whether the beneficiary is the user’s own account or a new one. The score does not change because the transaction changed.

3. Three placements of the transaction event

A transaction event can sit in one of three places relative to the session window:

• Inside the window. Score is current, applies to the session the transaction is part of. This is the case operators design for. The score informs the risk decision but does not commit to the specific transaction body.
• At the edge of expiry. The score is approaching the freshness boundary defined by the idle-decay policy. Vendors recommend a re-observation window before relying on the score. Whether a transaction at this edge is covered is a policy call.
• After the window. The session has timed out or the user has switched apps for longer than the decay tolerance. The score carried forward from the prior session may no longer represent the present user. Operators handle this by re-prompting, re-observing, or accepting elevated risk.

Each of these placements is a real production case. None of them is solved by recomputing the score more often: the score is still a property of the window, and the transaction still does not bind to it.

4. Score versus signature — the architectural point

The behavioural-biometrics score is a useful signal. It catches account takeover by a different human typing on the same device better than most static factors. It is not, however, a signature over the transaction. It is not what PSD2 RTS Article 5 [3] contemplates when it speaks of an authentication code dynamically linked to amount and payee. It is not what an issuer can cryptographically present in a dispute as proof that the device that confirmed the payment was the device that handled the preceding interaction.

Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — is structurally different: it produces a signature at each significant runtime event, including the moment the transaction body is confirmed and submitted, bound to that event by hash chain and by hardware-backed key. Behavioural biometrics describes the session probabilistically; EEI signs the event cryptographically. The two compose. They are not substitutes.

5. Cross-references

• Sibling articles in this theme: the-play-integrity-gap, the-fido2-submission-gap, the-sca-settlement-gap
• Architecture: /architecture/runtime-coherence, /architecture/evidence-token
• Comparison: /eei-vs-fingerprinting
• Glossary: /glossary — Evidence Token, Trusted Runtime Primitive

6. External references

[1] National Institute of Standards and Technology. SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management. pages.nist.gov/800-63-3/sp800-63b.html. Cited 2025-10-14.

[2] International Organization for Standardization. ISO/IEC 19989-1:2020 — Information security — Criteria and methodology for security evaluation of biometric systems. www.iso.org/standard/72402.html. Cited 2025-10-14.

[3] European Commission. Commission Delegated Regulation (EU) 2018/389 — Regulatory Technical Standards on Strong Customer Authentication, Article 5 (Dynamic linking). eur-lex.europa.eu/eli/reg_del/2018/389/oj. Cited 2025-10-14.