Oscilar Team

Device Intelligence and Behavioral Biometrics

Posted

Posted

Oscilar Team
Contents

Share this article

Last updated: October 2026

Device intelligence and behavioral biometrics are the two passive signal families fraud teams add when passwords and one-time codes stop being enough. Device intelligence tells you what is connecting and whether it is being disguised. Behavioral biometrics tell you whether the person using that device behaves like the account's owner. Together they catch spoofed devices, bots that act human, remote-access sessions and coached customers, provided baselines are built per user, friction is applied only when the risk warrants it, and privacy questions are settled before the first signal is collected.

TL;DR

  • Device intelligence identifies the device and connection behind a session and checks for disguise. Behavioral biometrics measure how the person on it types, swipes, taps and moves.

  • A device fingerprint is one input to device intelligence, not the whole of it. Attackers now tune spoofed fingerprints to look close enough to the customer's.

  • These signals catch what credentials miss: customers talked out of one-time codes, bots paced like people, people paid to pass bot checks, remote-access sessions and handed-over accounts.

  • They depend on baselines. With no history for a user, per-user deviation has nothing to compare against, so the value moves to device risk and to the application itself.

  • Behavioral data can count as biometric information under some state laws, with exemptions that differ by statute. Settle notice, retention and vendor handling with counsel before collecting.

  • Test any provider live on your own traffic. Behavioral signals were never collected on your historical data, so a retrospective score cannot prove them.

What is the difference between device intelligence and behavioral biometrics?

Device intelligence identifies the device and connection behind a session and checks whether either is being disguised. Behavioral biometrics measure how the person on that device interacts: typing rhythm, swipes, taps, mouse movement and navigation. Device intelligence asks what is connecting. Behavioral biometrics ask whether the person behaves like the account's owner, and fraud teams use both because each covers the other's blind spots.

Device intelligence starts with the device's attributes: hardware, operating system, browser configuration, language and time settings. It adds the connection, such as network type, IP reputation and proxy or VPN use. It then checks integrity, looking for emulators, rooted or jailbroken phones, and attributes that contradict each other. Finally it carries history: how often this device has been seen, on how many accounts, and with what outcomes.

Device fingerprinting is one input to that picture. A fingerprint is an identifier assembled from the device's attributes so the same device can be recognized on its next visit. Device intelligence asks the further questions: whether the fingerprint is stable, whether it looks spoofed, and what the device has done before.

Behavioral biometrics measure the person rather than the hardware. The FFIEC's 2021 authentication guidance describes it this way: "Behavioral biometric analysis can include data such as the customer's finger swipes, taps, keystrokes, and mouse usage." The same guidance treats device identification and behavioral biometrics as layered controls, and says cookies, geolocation or IP address matching are not effective controls when used alone.

Because the signals are collected in the background, behavioral biometrics are often called passive biometrics. When they run through the whole session rather than only at login, the practice is usually called continuous authentication, and behavioral biometrics authentication becomes one layer in it rather than a single gate.


Device intelligence

Behavioral biometrics

Question it answers

What is connecting, and is it disguised?

Does this person behave like the account's owner?

Typical signals

Device attributes, browser and OS configuration, network and IP reputation, emulator and tamper checks

Typing rhythm, swipe and tap patterns, mouse movement, navigation and hesitation

Strongest against

Spoofed and emulated devices, one device across many accounts

Bots, remote-control sessions, a different person on a familiar device

Blind spot

A fraudster using the customer's own device

A first session with no history to compare against

The two signal families fail in different places, which is the case for running them together.

What they catch that passwords and one-time codes miss

Passwords and one-time codes check what a person knows or holds. They say nothing about who is typing or what device is sending the request. Five patterns get through that gap.

Customers talked out of one-time codes

Impersonation calls now aim at the one-time code itself. A BSA/AML compliance manager at a credit union described impersonators getting members to approve the passcode: "They're giving out their credentials, and then they're getting through their system, and then they have full access to the account." The attacker then changes the password and the member is locked out of their own account.

Multi-factor authentication worked as designed in that sequence, because the code was valid. Device and behavioral signals ask a different question at login: is this the member's device, and does the session look like the member? A fraud manager at a credit union put the goal simply: "I would love to get something at the door when they are knocking at the door as opposed to once they're already into the system." The broader playbook for account takeover prevention sits on top of these signals.

Spoofed devices tuned to avoid step-up

Attackers know that a familiar device lowers the risk score. A consumer fraud strategy lead at a telecom carrier, outside financial services, described credential stuffing in which bad actors "try to match the fingerprint, the device fingerprint, right? So, they're just testing to see if their device fingerprint is close enough to the customer's device fingerprint, that they won't get stepped up."

That is why a fingerprint match should never settle the question on its own. Device intelligence looks for the marks of spoofing: emulators, attribute combinations no real device produces, and configurations that shift between sessions in ways real phones and browsers do not. One session cycling through many customer identities is itself a device signal, whatever the fingerprint says.

Bots that act human, and humans who pass bot checks

The same telecom fraud lead said attackers are programming bots to look more like real customers, taking longer on pages and scrolling around before acting. The opposite pattern appears too. A fraud and transaction monitoring lead at a business banking fintech described an attack where "they literally have a person sitting behind there and passing the captcha and passing the usual bot detection stuff."

A principal product manager for customer authentication at a money transfer company said CAPTCHA and similar bot prevention were not slowing attackers down. Behavioral signals help here because they look at the whole session rather than a single challenge. A bot paced to look human still tends to repeat itself, and a team of people working through many accounts tends to produce practiced, uniform sessions on similar devices.

Remote-access sessions

A scams and elder fraud program lead at a bank said rules-based monitoring did not have the behavior signals needed to detect the remote access tools used in social engineering, and that the team lacked any internal tool to detect them. A digital payments fraud analyst at a bank added that remote access on phones is harder to catch than on desktop computers.

Remote control leaves traces a session can be checked for: screen-sharing or remote-control software running on the device, input that arrives without the touch events a real hand produces, and cursor movement that does not fit the user's own pattern. Those traces are harder to see on phones, which is why mobile coverage deserves its own question in any evaluation.

Coached customers and handed-over accounts

Some of the hardest cases involve the real customer, on their own device, acting on a fraudster's instructions. Behavioral signals can show hesitation or a session that follows a script. Where the customer is being coached to send the money themselves, the signals have to be combined with transaction context; our guide to authorized push payment fraud covers that.

A fraud strategy lead at a consumer fintech pointed to another device pattern: two devices working on the same account in parallel, which can mean a money mule or an account handover. At onboarding, the same signals help with application fraud, where one device submitting many applications, or identity details pasted rather than typed, can point toward synthetic identities; our guide to detecting synthetic identity fraud covers those patterns.

How passive signals and baselines work

Device and behavioral signals mean little in isolation. A session is judged against two baselines: how customers in general interact with the application, and how this customer usually does. A fraud and AML manager at a digital consumer lender asked a provider about both, population-level profiling to detect anomalies and user-level profiling once someone becomes a customer.

The population baseline catches what no real customer does, such as a session that fills a long form in seconds or a device configuration that never appears among legitimate users. The per-user baseline catches what this customer does not do. The same money transfer company's product manager for customer authentication described the second case as looking at a login event, the IP address and the user's earlier behavioral data together to spot something anomalous.

Scoring deviation, not single signals

A single change is normal. Customers buy new phones, travel, and update their browsers. Several changes at once are not: a new device, a new network, an unfamiliar typing rhythm and a fast route to adding a payee, all in one session. Scoring the combined deviation rather than writing a rule per signal is what keeps the false alarms down.

The device identifier also has to stay stable through ordinary change. If a browser update, cleared cookies or an operating system upgrade makes a customer's device look new, every one of those sessions starts from no history.

How a session is typically assessed, step by step:

  1. Collect device and interaction signals passively, with no added step for the customer.

  2. Identify the device and check its integrity: emulation, tampering, spoofed attributes.

  3. Compare the session with the population baseline.

  4. Compare it with this customer's own baseline, where one exists.

  5. Combine the result with context such as the transaction, the payee and recent account changes.

  6. Decide: allow, step up, or hold for review.

Where baselines run thin

Per-user deviation needs history, and some businesses have little. A risk automation manager at a business lender was skeptical for that reason: "So like I don't know where that person is supposed to be normally logging in from." That lender's borrowers were vendors' salespeople with few touchpoints, so there was no normal pattern to deviate from.

Population signals and device risk still work on a first session. For lenders, the same fraud and AML manager at the digital consumer lender noted that once funds are disbursed, login activity matters less, and the application data does most of the work in judging fraud. That moves the value of these signals to the application session itself.

A newer test is coming from AI agents. A fraud and credit operations stakeholder at a streaming provider, outside financial services, asked how detection holds up as agents take on more of the form-filling that typing-time signals were built to read. Typing rhythm separates a person typing from text pasted from a notepad, but an agent acting for a real customer may be legitimate. It is one of the open questions for any behavioral model.

Friction only when the risk warrants it

Passive collection adds no steps for the customer. Most sessions should pass without the customer noticing anything, and step-up authentication should be reserved for sessions whose risk calls for it. Stepping up every new device or every unusual login trains customers to ignore challenges and pushes good customers away.

Scam detection at login is where friction is hardest to place. An authentication fraud strategy lead at the same bank as the digital payments fraud analyst cited earlier said scams are very tough to catch at that point, because many legitimate customers sit in the same population if you do not have the right indicators, so the team focused mostly on account takeover. Reducing fraud false positives depends on the same discipline: combining signals and context before adding friction.

Fairness needs its own check. Some behavioral signals, such as hesitation or slower typing, can skew toward older customers or customers using assistive technology. Combine signals rather than acting on one, and test outcomes by customer segment before a rule goes live.

Common mistakes

  • Treating a device fingerprint match as proof of identity.

  • Writing one rule per signal instead of scoring the combined deviation.

  • Stepping up every new device, so good customers absorb the friction.

  • Scoring per-user deviation for customers who have no history yet.

  • Collecting behavioral data before notice, retention and vendor handling are settled.

Privacy, consent and governance

Behavioral data can be biometric information under some state laws, and the exemptions for financial institutions differ by statute. What the texts say:

  • California. The CCPA (Cal. Civ. Code 1798.140) expressly lists "keystroke patterns or rhythms" and "gait patterns or rhythms" within biometric information. The CCPA also excludes personal information collected under the Gramm-Leach-Bliley Act.

  • Illinois. BIPA (740 ILCS 14/10) defines a biometric identifier as "a retina or iris scan, fingerprint, voiceprint, or scan of hand or face geometry", a closed list that does not name keystroke or gait. Section 25(c) exempts financial institutions subject to Title V of the Gramm-Leach-Bliley Act.

  • Texas and Washington. Texas's biometric statute (Tex. Bus. & Com. Code 503.001, amended effective January 1, 2026) and Washington's biometric identifier law (RCW 19.375) use definitions that do not list behavioral patterns, and both carve out fraud-prevention or security uses.

Whether any of these applies to a particular program depends on the data collected, the entity collecting it and the purpose. That is a question for counsel, and the answer should be settled before the first signal is collected.

The governance questions to answer in writing:

  • Purpose. What the signals are used for, and what they will not be used for.

  • Notice and consent. What customers are told, where, and whether consent is required.

  • Retention. How long raw signals and derived scores are kept, and when they are deleted.

  • Access. Who inside the institution and the provider can see the data, and how customer requests are handled.

  • Vendor handling. Where the provider stores the data and whether it is used to train models for other clients.

  • Model documentation. How scores are produced, tested and monitored, in a form a model risk reviewer can read.

How to evaluate a device or behavioral signal provider

Buyers tend to accept the problem quickly and push hard on proof. A head of card fraud at a consumer lender said they understood that traditional ways of detecting non-human behavior can be reverse engineered with today's AI tools, but still wanted to know why one provider would be more effective than another. These questions get to that answer.

  1. Can you prove the difference on our own traffic? Behavioral signals were never collected on your historical sessions, so they cannot be scored on a labeled file after the fact. The same head of card fraud put it this way: "You kind of have to sort of implement that and collect data real time in order to prove the value." The fraud strategy lead at the consumer fintech mentioned earlier made the same point about historical data sets and device and behavioral signals. A weak answer offers only a retrospective score on your past fraud.

  2. Does the model learn from our portfolio, from a consortium, or both? A fraud team lead at a card issuer asked exactly this, because a distinctive portfolio may not look like anyone else's. A weak answer cannot say which data trained the scores applied to your customers.

  3. Can an analyst see why a session scored high? A reason an analyst can read and defend is worth more than a precise-looking number. A weak answer is a single opaque score with no contributing factors.

  4. How heavy is the integration? Ask about web and mobile SDKs, what runs on the device, and how signals reach your decision point in real time. The BSA/AML compliance manager at the credit union quoted earlier said their heavily customized online banking made plug-and-play API calls hard. A weak answer assumes a standard stack and has no plan for yours.

  5. How do you handle spoofing, emulators, remote access and automated agents? Ask to see how the signals are combined into a decision, with examples from sessions like yours. A weak answer points to the size of a signal list instead of showing how the signals are used.

  6. What data do you collect, where is it stored, for how long, and who can access it? The answers should map onto the governance list above. A weak answer leaves retention or reuse for model training unspecified.

Frequently asked questions

Is device fingerprinting the same as device intelligence?

No. Device fingerprinting builds an identifier from a device's attributes so it can be recognized on a later visit. Device intelligence uses that identifier as one input, and adds integrity checks for emulation and tampering, network and IP context, and the device's history across accounts. A fingerprint can be spoofed to look familiar, which is why it should not decide a session on its own.

Do behavioral biometrics add friction for customers?

Not by themselves. Behavioral biometrics are collected passively in the background, so most customers see no extra step. Friction comes from what the institution does with a high-risk score, such as a step-up challenge, and that should be reserved for sessions whose combined risk warrants it.

Are behavioral biometrics covered by biometric privacy laws?

Under some statutes, possibly. California's CCPA expressly lists keystroke and gait patterns as biometric information but excludes data collected under the Gramm-Leach-Bliley Act. Illinois BIPA's definition does not list keystroke or gait and exempts financial institutions subject to Title V of that Act, while Texas and Washington carve out fraud-prevention and security uses. Whether a given program is covered is a question for counsel.

Can behavioral biometrics stop scams where the customer is coached?

Not alone. When the real customer is on their own device, the device looks familiar and the credentials are correct. Behavioral signals can show hesitation, a scripted session or remote-access software on the device, but they cannot tell whether the payment was the customer's own idea. They need to be combined with transaction and payee context.

Where Oscilar fits

At Oscilar, device and behavior intelligence is one component of a unified platform: real-time data fabric, device and behavior intelligence, rules, and case management in one stack. That lets the signals described here be weighed alongside transaction data and rules rather than in a separate tool. To see how that works in practice, explore device and behavioral intelligence on the Oscilar platform.

Oscilar Team

The Oscilar Team is comprised of experts from many domains of risk operations. These articles express viewpoints and knowledge from a variety of sources and contributors across the organization.

DISCLAIMER

The content on this website is provided for informational purposes only and does not constitute legal, tax, financial, investment, or other professional advice. Any views or opinions expressed by quoted individuals, contributors, or third parties are solely their own and do not necessarily reflect the views of our organization.

Nothing herein should be construed as an endorsement, recommendation, or approval of any particular strategy, product, service, or viewpoint. Readers should consult their own qualified advisors before making any financial or investment decisions.

Oscilar makes no representations or warranties as to the accuracy, completeness, or timeliness of the information provided and disclaims any liability for any loss or damage arising from reliance on this content. This website may contain links to third-party websites, which Oscilar does not control or endorse.