Behavioural Biometrics Buyer's Guide

Behavioural biometrics products promise to spot bots, account takeover and coached scam victims from how people type, swipe and move, yet most buyers cannot tell from a demo whether the models will work on their own users. These products collect signals such as keystroke timing, touch pressure, swipe and mouse dynamics, device handling and session navigation, then score sessions for risk in real time. They are bought by banks, payment firms, e-commerce and contact centres, mostly to reduce fraud without adding friction. This vendor-neutral guide helps fraud, identity and privacy teams define requirements, compare products, question vendors and design a proof of concept with measurable results. For how these signals work in a fraud programme, see the Transaction Monitoring and Behavioural Biometrics Guide.

Key takeaways

Buy for a named fraud problem: bots, account takeover, new account fraud or authorised push payment scams each need different signals and models.
Judge on your own data: detection rate at a fixed false positive rate, measured in a blind proof of concept, matters more than any vendor benchmark.
Treat it as risk scoring, not authentication: behaviour feeds step-up and transaction decisions; it does not replace a strong authenticator.
Settle privacy early: behavioural data used to uniquely identify a person can be special category biometric data, so plan the lawful basis, DPIA and retention before the pilot.
Check the SDK as carefully as the model: script and SDK weight, tamper resistance and data flows decide whether you can deploy it at all.

Define requirements

Fraud problem and losses: which fraud types you lose money to today, through which channels, and what the target reduction is. See the Account Takeover Prevention Guide and the Authorised Push Payment (APP) Fraud Guide.
Regulatory drivers: in the EU, the PSD2 strong customer authentication standards (Commission Delegated Regulation (EU) 2018/389) require transaction monitoring, and exemptions based on transaction risk analysis depend on monitoring that considers abnormal spending or behavioural patterns, device and location signals, with reference fraud rates set in the Annex. In the UK, mandatory APP scam reimbursement, in force since 7 October 2024 with a maximum of £85,000 per claim split between sending and receiving firms, has changed the business case for spotting scam victims in session.
Channels: web, native mobile, contact centre and agent-assisted journeys. Coverage differs widely between products.
Decision points: sign-in, payee creation, payment, profile change, account recovery. Each needs a real-time score with a latency budget.
Existing stack: fraud decision engine, CIAM, device intelligence and bot management. Decide whether behaviour is a separate product or a module of one you already own. See the Bot Management Buyer's Guide.

Signal types and what they detect

Signal family	Examples	Good at detecting	Limits
Input dynamics	Keystroke timing, typing cadence, paste events, mouse curves, touch pressure and swipe shape	Bots and automation, credential stuffing, a different person using the account	Needs enough interaction; weak on short mobile journeys
Device handling	Phone angle, motion sensors, hand used, screen orientation changes	Emulators, device farms, unfamiliar handling of a known device	Sensor access varies by platform and browser
Navigation and familiarity	Path through the app, hesitation, use of shortcuts, time on fields, copying account numbers	Account takeover by a stranger who does not know the app; mule account behaviour	New users and redesigned apps reduce confidence
Coaching and remote control indicators	Long pauses, active phone call during banking, remote access tool present, unusual typing of payee details	Authorised push payment scams and remote access fraud	Strongly dependent on mobile SDK permissions and call-state access
Population and cohort signals	Behaviour compared with all users, not only the account owner	First-session fraud on new accounts with no profile	More false positives for atypical but genuine users

Evaluation criteria

Area	What good looks like	How to verify
Detection performance	Detection rate and value detected at a false positive rate you choose, per fraud type	Blind proof of concept on your labelled fraud cases
Time to value	Useful scores for new and returning users within weeks, with clear profile-building periods	Score coverage in the first and fourth week of the pilot
Explainability	Reason codes per score that analysts and customers can be given; model documentation	Review 50 alerts with your analysts
Real-time integration	Score returned within your latency budget at the decision point; API or event stream to the decision engine	Measure p95 latency in the pilot
SDK quality	Small footprint, no impact on page performance or app stability, obfuscation and tamper detection, support for your frameworks	Performance test; app store and accessibility review
Coverage	Web, iOS, Android and, where needed, contact centre; parity of signals across them	Signal list per platform
Data handling	Data minimised, no capture of typed content in sensitive fields, pseudonymised identifiers, configurable retention, regional processing	Data flow diagram; sample payload inspection
Model governance	Documented retraining, drift monitoring, fairness testing across user groups, change notices before model updates	Model governance pack; change history
Consortium data	Clear terms on whether your data improves a shared model, and what you receive in return	Contract review
Vendor security	Independent certifications, tenant isolation, controlled support access, incident notification terms	Assurance reports and contract clauses

Ask every vendor to report results in the same way: fraud detected (count and value), genuine sessions flagged, and analyst workload, at the same alert volume. Comparing one vendor's "detection rate" with another's "accuracy" tells you nothing.

Privacy, fairness and legal checks

Special category data: the UK ICO's biometric recognition guidance gives keystroke, gait and gaze analysis as behavioural examples, and treats biometric data as special category where it is processed to uniquely identify a person. Whether your use does that depends on design, so document your analysis in a DPIA. The ICO notes this guidance is under review after the Data (Use and Access) Act 2025.
Transparency: tell customers in your privacy notice that behavioural and device signals are used for fraud prevention and security.
Minimisation: the SDK should capture timing and movement, not the content typed into passwords, card numbers or messages.
Fairness: people with motor impairments, older users and assistive technology users may behave atypically. Require per-group false positive analysis and an accessible route through any step-up.
Automated decisions: where a score alone blocks a payment or account, check the rules on solely automated decision-making in your jurisdiction and give customers a way to challenge.
Retention: agree how long raw signals and profiles are kept, and deletion when an account closes.

For the wider biometric law picture, see the Biometric Privacy Laws Map.

Questions to ask vendors

Which fraud types are your models built for, and which signals drive each one?
What detection rate and value detected did comparable customers see at a false positive rate of our choosing, and can we run a blind test on our own labelled data?
How long does it take to build a reliable profile for a returning user, and how do you score first-time users?
What exactly does the SDK collect on each platform? Show us a raw payload from a sensitive field.
How do you detect emulators, automation frameworks, remote access tools and tampering with your SDK?
What reason codes do you return, and can our analysts explain a decision to a customer or a complaints body?
How do you test models for bias against older, disabled or assistive technology users?
Is our data used to train a shared or consortium model? Can we opt out, and what changes if we do?
How are model updates tested and announced, and can we hold a model version while we validate a new one?
Where is data processed and stored, and which sub-processors are involved?

Red flags

Performance claims based only on a vendor-run test, with no option for a blind test on your data.
A single "accuracy" figure with no false positive rate or alert volume.
Behavioural scoring sold as a replacement for strong authentication rather than a risk signal.
SDKs that capture field contents, screen recordings or contacts without a clear need.
No reason codes, or scores that cannot be explained to a customer whose payment was stopped.
Silent model updates that shift alert volumes without notice.
Contract terms that give the vendor broad rights to reuse your customer data.

Proof of concept

Agree the fraud types in scope, the success metric (for example detection rate at a fixed alert volume) and the decision points before installing anything.
Complete the DPIA and update the privacy notice for the pilot population.
Deploy the SDK in passive mode on web and mobile, with scores logged but not acted on; measure page and app performance impact.
Run for long enough to cover profile building and at least one normal monthly cycle, typically six to eight weeks.
Score blind: share fraud labels with the vendor only after scores are frozen, then compare with your current controls on the same sessions.
Review a sample of high-risk genuine sessions with analysts to understand false positives and reason codes, including assistive technology users.
Test resilience: emulators, automation, remote access tools and SDK tampering in an authorised test environment.
If moving to live decisions, start with step-up or analyst review, not blocking, and keep a switch to return any decision point to passive mode.

Measures to track in production: fraud value prevented per decision point, false positive rate and customer friction rate, analyst alerts per thousand sessions, score coverage across channels, and model drift alerts.

Framework mapping

Framework	Reference	Relevance
EU PSD2 RTS	Delegated Regulation (EU) 2018/389, Articles 2 and 18	Transaction monitoring and transaction risk analysis exemption
NIST CSF 2.0	DE.CM-03, DE.AE-02	Monitoring personnel activity and technology usage; analysing adverse events
NIST SP 800-53 Rev. 5	SI-4, IA-11, PT-2, RA-3	System monitoring, re-authentication on risk, authority to process PII, risk assessment
UK GDPR	Articles 9 and 35	Special category biometric data; data protection impact assessment

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support across customer identity, authentication and fraud prevention. Browse vendors in our products directory or contact us.

Behavioural Biometrics Buyer’s Guide: How to Evaluate Signals, Models and Privacy Risk