Fraud rules catch what the team has already seen, behavioural biometrics catch how a session is being driven, and most programmes buy one expecting it to fix the weaknesses of the other. Rules are cheap to explain and fast to change, but they flood analysts with false positives and fraudsters learn the thresholds by probing them. Behavioural biometrics score typing, touch and navigation patterns, which exposes bots and coached victims, but they need profile history, raise data protection questions and can be mimicked. This guide compares the two as detection approaches, not products: threat model, architecture, accuracy, friction, evasion, privacy and how to layer them with device and identity signals. It is for fraud strategy leads, fraud analytics teams and digital channel security architects. For the payment monitoring baseline and UK reimbursement context see the Transaction Monitoring and Behavioural Biometrics Guide, which this page builds on rather than repeats.
Key takeaways
- They answer different questions. A rule asks whether this event matches a pattern someone wrote down; a behavioural model asks whether the human, or machine, driving this session behaves like the genuine customer acting freely.
- Accuracy must be measured on rare events. Fraud is a tiny share of traffic, so raw accuracy is meaningless; compare approaches on detection rate, false positive rate and alert precision at a fixed operating point.
- Both can be evaded, in different ways. Rules fall to threshold probing and splitting; behavioural models fall to replayed or synthetic input and, above all, to the genuine customer being coached in a remote access or impersonation scam.
- Privacy depends on purpose. Under UK GDPR behavioural data becomes special category biometric data when processed to uniquely identify a person, so a session anomaly score and a "this is the same user" match can sit under different legal conditions.
- Layering beats replacement. Keep rules for hard policy and known scenarios, use behavioural scores as features and step-up triggers, and combine both with device, identity and payee signals at one decision point.
The short answer
Choose rules first when you need transparent, auditable controls for known scenarios, regulatory minimums and hard business policy (block payments to a sanctioned country, hold first payments above a value to new payees). Add behavioural biometrics when your losses come from sessions that look legitimate on every transactional attribute: account takeover by a different human on a trusted device, scripted bots that pass device checks, and authorised push payment scams where the real customer is being directed by someone else. Few organisations should run behavioural biometrics alone: it produces a risk score, not a decision, and it needs rules or models downstream to turn that score into an action. See the Fraud Rules and Machine Learning Models Guide for how rules and supervised models are governed together.
Side-by-side comparison
| Dimension | Rules-based detection | Behavioural biometrics |
|---|---|---|
| Core question | Does this event match a known risky pattern or breach a policy threshold? | Is the session driven by the genuine user, acting freely, or by a bot or another person? |
| Main inputs | Transaction amount, payee age, velocity, geography, account age, list matches | Keystroke timing, touch pressure and swipe shape, device motion, mouse dynamics, navigation path, hesitation, paste events |
| When it decides | At an event: login, payment submission, profile change | Continuously through the session, summarised at decision points |
| Cold start | Works from day one with expert-written logic | Population-level bot and anomaly signals work early; per-user profiling needs several sessions |
| Explainability | High: the rule that fired is the reason | Medium to low: reason codes summarise model features |
| Change speed | Minutes to days, by the fraud team | Model retraining and vendor or data science release cycles |
| Typical false positive driver | Static thresholds hitting legitimate rare behaviour (house deposits, travel) | Behaviour change from injury, new device, accessibility tools, shared devices |
| Main evasion | Threshold probing, transaction splitting, mule ageing | Input replay and synthetic movement, and coached genuine users |
| Privacy footprint | Transaction and account data already held for the service | New interaction telemetry, possibly special category biometric data depending on purpose |
| Integration point | Decision engine on the server side | Client SDK or script in the app and web journey, scores sent to the decision engine |
Rules-based detection in depth
Threat model and architecture
Rules encode known fraud scenarios and policy. In payments, Commission Delegated Regulation (EU) 2018/389 Article 2 sets the floor: transaction monitoring must take into account at least lists of compromised or stolen authentication elements, the amount of each payment, known fraud scenarios, signs of malware in authentication sessions and, where the provider supplies the access device or software, a log of its use and abnormal use. A rules engine sits server side, reads the event plus enrichment (customer history, payee risk, list hits) and returns allow, step-up, hold or decline. Mature programmes keep rules in version control with an owner, a rationale, a back-test result and an expiry review date for each rule.
Where rules work well
- Hard policy: sanctions, product limits, prohibited merchant categories and regulatory holds that must be applied the same way every time.
- Fresh scenarios: a new mule pattern reported by a consortium can be written as a rule the same day, long before a model has labelled data. See the Fraud Data Sharing and Consortium Intelligence Guide.
- Explanations owed to customers and regulators: the fired rule gives a clear reason for a hold.
Failure modes
- Rule sprawl: hundreds of overlapping rules, many never retired, each adding alerts; nobody knows the marginal value of any one.
- Threshold probing: fraudsters send test payments at different values and timings, see which are held, then stay just under the line. Static thresholds leak their own position.
- Blind to the coached customer: in an authorised push payment scam the device, credentials and authentication are genuine, so only payment attributes remain, and a large first payment to a new payee is also normal life.
Behavioural biometrics in depth
Threat model and architecture
Behavioural biometrics collect interaction telemetry through a mobile SDK or web script: timings between key presses, touch area and pressure, swipe curvature, gyroscope and accelerometer readings, mouse movement and the order and speed of navigation. The data goes to a scoring service that returns signals such as bot likelihood, user mismatch against the profile, signs of remote control and signs of duress or coaching (long pauses, unusual hesitation on the payee screen, pasted reference text). The decision engine consumes those scores alongside rules. The ICO describes biometric data under UK GDPR Article 4(14) as personal data from specific technical processing relating to physical, physiological or behavioural characteristics that allow or confirm unique identification, and gives the way someone types as a behavioural characteristic.
Where behavioural biometrics work well
- Bots and automation: scripted sessions produce input timing and movement that differ from human interaction, complementing the Bot Management Guide controls at the edge, such as the credential stuffing (OWASP OAT-008, ATT&CK T1110.004) and account creation (OAT-019) threats in the OWASP Automated Threat Handbook.
- Different human on a trusted device: account takeover where the device and password are known but the typist is not. See the Account Takeover Prevention Guide.
- Remote control and coaching: sessions driven through remote access tools (ATT&CK T1219 Remote Access Tools) show cursor and input patterns unlike local use; coached victims show hesitation and switching patterns. See the Remote Access Scam and Screen Sharing Fraud Guide.
Failure modes
- Thin sessions: a returning user who taps once on a saved payee produces little signal; the score is weak exactly where speed matters.
- Legitimate behaviour change: injury, a new phone, assistive technology, a different keyboard language or a shared household device all shift patterns. Unmanaged, these become false positives that fall unevenly on some customer groups.
- Treating the score as the decision: a high mismatch score with no intervention design simply moves the problem to the contact centre.
Accuracy and false positive trade-offs
Fraud is rare, so accuracy figures mislead. Google's machine learning guidance shows the problem plainly: where 1% of cases are positive, a model that always predicts negative scores 99% accuracy while catching nothing. Compare rules and behavioural scores on the same labelled period using measures that respect imbalance.
| Measure | Definition | What it tells you |
|---|---|---|
| Detection rate (recall) | Fraud cases flagged divided by all fraud cases | How much fraud the approach sees at the chosen threshold |
| False positive rate | Genuine events flagged divided by all genuine events | Customer friction and lost sales |
| Alert precision | Confirmed fraud divided by alerts raised | Analyst efficiency; low precision means queues of genuine customers |
| Value detection rate | Fraud value stopped divided by total fraud value | Whether the approach catches the expensive cases, not just many small ones |
| Incremental detection | Fraud caught by B that A missed, at the same false positive budget | The real business case for adding the second approach |
- Fix the friction budget first: agree how many genuine customers per thousand you will challenge, then compare how much fraud each approach catches inside that budget. Comparing at different thresholds proves nothing.
- Watch label delay: scam and first-party fraud labels can arrive weeks later through claims and disputes, so a recent window flatters any approach.
- Measure by segment: new versus returning customers, mobile versus web, older customers and assistive technology users. Behavioural models often perform differently across these groups, and so do rules keyed on age of account or device.
- Use behavioural scores to cut rule noise: one of the most productive patterns is requiring a rule hit and a behavioural risk signal before a hard hold, while letting a rule hit with a clean session pass with a light warning. That often lowers false positives without lowering detection; prove it with a back-test.
The Fraud Metrics and KPIs Guide covers board-level reporting; the measures above are for the engineering comparison.
Evasion: how each approach is beaten
| Evasion technique | Effect on rules | Effect on behavioural biometrics | Defensive response |
|---|---|---|---|
| Threshold probing and splitting | High: attacker learns and stays under limits | Low: probing sessions still show automation or unusual navigation | Randomised and cumulative thresholds, velocity across payees and channels, behavioural score as a co-condition |
| Bot mimicry (synthetic movement, replayed human input) | Low impact: rules rarely look at input | Medium: well-built mimicry lowers bot scores | Combine with device integrity and app attestation, challenge on mismatch, track repeated identical input traces across accounts |
| Human fraud farms | Medium: real humans create plausible transactions | Medium: genuine human input, but mismatch to the account owner | Profile mismatch plus device and network clustering across many accounts |
| Remote access scam | High: genuine device and credentials | Low to medium: remote control and coaching signals are visible if the SDK collects them | Detect screen sharing and remote control, scam-specific warnings, holds with trained call-back |
| Coached victim typing themselves | High | Medium: hesitation and context switching can show, but the typist is genuine | Payee risk, confirmation of payee, purpose questions, delay for high-risk first payments |
| Mule account ageing | High: aged accounts pass account-age rules | Medium on the receiving side if the receiving firm scores mule behaviour | Receiving-side monitoring and consortium data |
On mobile, apps can reduce the remote access attack surface directly. Android's fraud prevention guidance describes FLAG_SECURE, which blocks screenshots and display on non-secure displays, and the HIDE_OVERLAY_WINDOWS permission from Android 12 (API 31) to opt out of third-party overlays; the same guidance notes that FLAG_SECURE does not reliably stop overlay attacks. These platform controls reduce what a remote operator can see; behavioural signals then indicate when someone is still driving the session.
Privacy, consent and fairness
- Purpose decides the category: the ICO states that not all biometric data is automatically special category; it becomes special category when processed to uniquely identify someone. A "same user as before" match is identification-like; a population-level bot score may not be. Document the purpose of each signal in the data protection impact assessment.
- Lawful basis and condition: where special category data is processed you need an Article 9 condition as well as a lawful basis. Consent is a weak fit for fraud controls the customer cannot refuse, so most firms rely on other conditions; take legal advice and record the reasoning. The ICO notes its biometric guidance is under review following the Data (Use and Access) Act, so check the current text.
- Automated decisions: EU GDPR Article 22 gives a right not to be subject to solely automated decisions with legal or similarly significant effects, with exceptions including contract necessity, and requires safeguards such as human intervention and the ability to contest. A declined payment or closed account driven only by a score needs a review route. UK rules on automated decision-making have changed under the Data (Use and Access) Act; confirm the current position.
- EU AI Act: Annex III lists biometric categorisation and emotion recognition systems as high risk, and excludes biometric verification whose sole purpose is confirming a person is who they claim to be from remote biometric identification. Its creditworthiness entry excludes AI used to detect financial fraud. Map each behavioural feature against these definitions; avoid inferring emotional state or protected attributes. See the Biometric Privacy Laws Map for US state laws.
- Rules are not privacy-free: rules keyed to postcode, nationality or age can create indirect discrimination. Review rule features with the same fairness lens as models.
Layering with device and identity signals
Neither approach should decide alone. A practical decision point at login and at payment submission takes four groups of input: identity (authentication method and age, recent credential or contact detail changes), device (integrity, emulator, attestation, known device; see the Device Intelligence and Fingerprinting Guide), behaviour (bot, mismatch, remote control, coaching scores) and transaction (amount, payee risk, velocity, rules fired).
| Signal combination | Likely situation | Proportionate action |
|---|---|---|
| Known device, clean behaviour, rule hit on large amount | Genuine rare payment | Allow with confirmation of payee or light warning |
| Known device, coaching or remote control signals, new payee | Authorised push payment scam in progress | Scam-specific warning, hold and trained call-back. See the Authorised Push Payment (APP) Fraud Guide |
| Known device, user mismatch, recent password reset | Account takeover by a different person | Step-up with a phishing-resistant factor, block sensitive changes |
| New or emulated device, bot signals, no rule hit | Automated attack testing credentials or creating accounts | Challenge or block at edge, rate limit, feed to bot defences |
| New device, clean human behaviour, clean transaction | New phone or genuine new customer | Allow, start profiling, apply new-device limits for a short period |
Worked scenario
A retail bank's rules flag 2.0% of outbound faster payments for review, and analysts confirm fraud in a small fraction of alerts. Losses are concentrated in scams on trusted devices. The team runs a behavioural SDK in observe-only mode for eight weeks, then back-tests three policies on the same labelled weeks at the same 2.0% review budget: rules alone; rules with the behavioural score as a co-condition for holds; and rules plus holds triggered by coaching signals on first payments to new payees. The comparison is made on detection rate, value detection and alert precision per segment. Whichever policy wins, the bank keeps sanctions and limit rules unchanged, retires rules whose alerts the combined policy makes redundant, and adds a manual review route for any customer held twice in thirty days. The illustration shows the method; the figures are not benchmarks.
How to implement
- Baseline the rules: list every rule with owner, purpose, hit rate, precision and last review; retire rules with no confirmed fraud in a defined period after a back-test.
- Define the decision points: login, new payee, payment submission, contact detail change, and agree the actions available at each.
- Complete the DPIA before collection: purpose per signal, retention, Article 9 condition if needed, vendor processing terms, fairness testing plan.
- Deploy behavioural collection in observe mode: scores logged, no customer impact; check SDK performance and data minimisation.
- Back-test at a fixed friction budget: compare policies on the measures above, by segment, with delayed labels included.
- Pilot on a ring: one channel or a percentage of traffic, with a champion and challenger split and a clear rollback (revert to rules-only policy by configuration).
- Train interventions: scam warnings and call-back scripts tied to the signal that fired, not generic prompts.
- Govern continuously: quarterly rule review, model drift monitoring, fairness checks and a feedback loop from confirmed cases and complaints.
Decision guidance
- Small organisations and low digital volume: start with well-governed rules and device signals; behavioural profiling needs volume and repeat sessions to pay back.
- High-volume digital banks and payment firms with scam exposure: layered rules plus behavioural signals, because reimbursement regimes such as the UK protections in force since 7 October 2024 put scam losses on the firm.
- Marketplaces and ecommerce: behavioural bot signals at sign-up and checkout are often more useful than per-user profiling, which customers rarely build at low visit frequency.
- Highly regulated decisions: keep the final hold or decline traceable to reason codes, whichever approach produced the signal.
Detection and measurement
- Log: every decision with inputs, rules fired, behavioural reason codes, action taken and outcome, so any case can be replayed (NIST SP 800-53 AU-6 review and SI-4 monitoring).
- KPI 1: fraud value detection rate by channel and fraud type.
- KPI 2: false positive rate and genuine customers challenged per thousand sessions.
- KPI 3: alert precision per rule and per behavioural signal.
- KPI 4: share of scam cases where a coaching or remote control signal was present but no intervention fired.
- KPI 5: complaint and override rate by customer segment, as a fairness indicator.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-03, DE.AE-02 | Monitoring personnel activity and technology usage; analysing potentially adverse events |
| NIST SP 800-53 Rev 5 | SI-4, AU-6, IA-11 | System monitoring, audit review, re-authentication as step-up |
| MITRE ATT&CK v20 | T1078, T1110.004, T1219 | Valid accounts, credential stuffing, remote access tools in scams |
| OWASP Automated Threat Handbook | OAT-008, OAT-019, OAT-001 | Credential stuffing, account creation, carding |
| EU payments law | Delegated Regulation 2018/389 Articles 2 and 18 | Transaction monitoring factors and real-time risk analysis |
| EU GDPR / UK GDPR | Articles 4(14), 9, 22 | Biometric data definition, special category conditions, automated decisions |
Common failure patterns
- Buying behavioural biometrics to replace rules: scores arrive with nowhere to go, and hard policy controls are lost.
- Comparing at different thresholds: a vendor trial shows more fraud caught at double the challenge rate, and the business case is built on it.
- Never retiring rules: each new rule adds alerts, analysts rubber-stamp queues, and real cases are missed.
- Skipping the DPIA: telemetry is collected before purpose and category are settled, forcing a costly rework.
- Ignoring the coached customer: controls tuned for impostors pass scams made by genuine users on genuine devices, the pattern seen in the Arup deepfake fraud, where an employee was deceived into authorising transfers himself.
Practitioner checklist
- Inventory every fraud rule with owner, purpose, precision and review date.
- Agree a friction budget before comparing any detection approach.
- Measure detection, false positive rate and alert precision by segment, including delayed labels.
- Run behavioural collection in observe mode before it affects customers.
- Document the purpose and legal category of each behavioural signal in a DPIA.
- Use behavioural scores as co-conditions to cut rule false positives.
- Combine identity, device, behaviour and transaction signals at one decision point.
- Give every automated hold a human review and contest route.
- Apply platform controls against screen capture and overlays in mobile apps.
Standards and references
- EUR-Lex: Commission Delegated Regulation (EU) 2018/389 on strong customer authentication
- ICO: Biometric data guidance, key data protection concepts
- GDPR: Article 22, automated individual decision-making
- EU AI Act: Annex III high-risk AI systems
- Payment Systems Regulator: APP fraud reimbursement protections
- OWASP: Automated Threats to Web Applications
- Android Developers: Secure sensitive activities
- Google for Developers: Accuracy, precision and recall
Related NHI Mgmt Group resources: Behavioural Biometrics Buyer's Guide, Biometrics Guide, Behavioural vs Physiological Biometrics, Fraud Prevention Guide for Digital Businesses.