What a behavioral biometrics SDK actually does
Behavioral biometrics is a category of authentication and fraud signals derived from the way a legitimate user interacts with an app, rather than from what they know (a password) or what they are (a fingerprint). A behavioral biometrics SDK is the library that lives inside your mobile or web application and produces those signals in real time.
The problem it solves is straightforward. A password can be phished, a session cookie can be stolen, and a device fingerprint can be re-used. But an attacker sitting in someone else's session moves differently: they type faster, paste credentials instead of typing them, complete flows at machine speed, and skip the small hesitations a legitimate user shows. A behavioral biometrics SDK captures those differences and hands your app a verdict it can act on before the transaction reaches your backend.
The right way to think about it: behavioral biometrics is an additional signal layer. It does not replace your existing device fingerprinting, WAF, or transaction-monitoring stack. It adds a behavior-of-user dimension none of those tools can produce on their own.
What ValorQ's SDK measures
ValorQ's SDK captures nine dimensions of behavioral signal grouped into four families. Each is compared, per session, against the user's own history — not a population average.
Timing signals
- Step timing. Time spent on each screen of a flow, compared to that user's personal baseline. A returning user who normally takes 4–7 seconds to review a transfer amount and suddenly completes the same screen in 340 ms is producing signal.
- Session velocity. Total time to complete a flow, versus a rolling baseline. Attackers running scripted takeovers tend to blaze through flows at superhuman speed.
Interaction signals
- Credential behavior. How credentials are entered — typed with natural rhythm, or pasted from a clipboard. Zero warm-up required; the first suspicious paste on a sensitive field is enough.
- Interaction patterns. Touch cadence, tap placement variance, scroll rhythm. Legitimate users are noisy in consistent ways. Attacker-controlled sessions are either too precise or too chaotic.
- Navigation flow. The path a user takes through your screens. Compromised sessions tend to move linearly toward the payout, skipping the exploratory taps a real user makes.
Motion signals
- Device motion. On mobile, the accelerometer and gyroscope pick up the tiny variance of a human holding a phone. Emulators and rooted farms produce characteristically static or synthetic motion.
Behavioral drift
- Profile deviation. A session that diverges from an established user's cumulative profile is treated as high-risk — even when the credentials are valid. This is how ValorQ catches account takeovers that clear MFA.
- Risk aggregation. All active signals are combined into a single composite score from 0 to 100, weighted by severity and confidence, updated continuously as the session progresses.
The verdict lands in one of three tiers: CLEAR (0–34) means no action; REVIEW (35–69) triggers step-up authentication; BLOCK (70–100) stops the flow immediately. Every score is traceable back to the signals that produced it — no black box, no unfalsifiable ML judgment.
Platforms supported
ValorQ ships four native packages. They share one scoring model and one risk verdict, so signal from one platform is comparable to signal from another. Baselines are platform-specific by design — a user's tap rhythm on iPhone differs from their tap rhythm on a laptop — and ValorQ handles that separation for you.
- Android SDK — Kotlin-native. First-class Jetpack Compose support. Coroutines throughout. Encrypted local baseline storage via
EncryptedSharedPreferences. StateFlow interface for reactive UI integration. - iOS SDK — Swift Concurrency-native. Actor-isolated scoring engine, Keychain-backed baseline storage, SwiftUI ViewModifiers you can drop into existing screens.
- Web SDK — TypeScript. Ships React components and React hooks for direct binding of risk state into your UI. Local baseline persistence via IndexedDB.
- React Native SDK — Extends the core client with native storage and AppState lifecycle management. Platform detection is automatic, so behavioral baselines stay correctly separated per surface.
On-device vs cloud — why architecture matters
The single most important architectural decision in a behavioral biometrics SDK is where the scoring happens. ValorQ scores on-device by default. This is not a minor detail; it changes what data leaves the customer's environment and how much of your app falls under regulated data-processing scope.
A cloud-scored architecture streams every touch, keystroke, and motion sample to a vendor backend for analysis. That means (a) every session incurs network latency before a verdict lands, (b) the vendor becomes a data processor for behavioral data that likely qualifies as personal under GDPR/DPDP, and (c) an outage on the vendor side means your app either fails open or fails closed — neither is a good option.
An on-device architecture scores locally. The risk callback fires immediately — before any backend transaction is authorized. In ValorQ's SDK-only deployment, no behavioral data ever leaves the device, so the vendor never becomes a processor for regulated data. When a session risk needs to be queried server-side (say, to gate a transfer above a threshold), a small verdict object can be sent — not the raw behavioral stream that produced it.
The trade-off is that on-device scoring is constrained to what you can compute on the client. ValorQ's scoring engine is built on robust statistical methods (MAD-based z-scores against per-user baselines) precisely because those methods are fast, statistically robust, and effective without needing gigabytes of population data.
Three deployment models
Behavioral biometrics is not a monolithic capability. Different teams need different depths of integration, and forcing a heavyweight backend on a team that just wants to see signals in a test environment is a good way to kill the pilot. ValorQ ships three tiers you can grow through.
Model 1 — SDK Only
All scoring happens on-device. Zero network calls from the SDK. Risk callbacks fire locally. Baselines persist in encrypted local storage. There is no vendor backend in the loop, so ValorQ never enters your data-processing boundary. This is the fastest way to evaluate — a mobile team can integrate and start seeing signals in a test build in a few days.
Model 2 — SDK + Backend
Adds a lightweight backend that receives events, re-scores against full user history, and hydrates baselines across device upgrades. Your app queries session risk from your own backend via API before authorizing high-value actions. This is the model most production deployments settle on: enough infrastructure to persist baselines across a device swap, but no more.
Model 3 — Full Platform
Adds the observability layer for enterprise security teams: a live operations dashboard, fleet analytics, webhook alerts on tier changes, audit log and compliance export. Aimed at teams that need SOC/fraud-ops workflow around the raw signal, not just the signal itself.
Developer experience
Integration should be quiet. The SDK sits in the background, watches the user's natural interaction with your existing screens, and surfaces a single risk state you subscribe to.
Two things happen when you integrate:
- You wrap a flow. A flow is a bounded sequence of screens the user moves through — login, add-a-payee, transfer, checkout. You tell the SDK when a flow starts and ends so it can score relative to that flow's baseline.
- You register a risk callback. Whenever the composite risk crosses a tier boundary, ValorQ fires
onRiskChange with the new score, tier, and the signals that produced it. Your app decides what to do — allow, step-up, block.
A short example (Web / TypeScript)
import { ValorQ } from "@valorq/web";
const valorq = ValorQ.init({
tenantId: process.env.NEXT_PUBLIC_VALORQ_TENANT,
mode: "sdk-only", // or "with-backend"
});
valorq.onRiskChange(({ score, tier, signals }) => {
if (tier === "BLOCK") {
stopFlow();
reportToBackend({ score, signals });
} else if (tier === "REVIEW") {
requireStepUp();
}
});
// Wrap a sensitive flow
valorq.startFlow("wire-transfer");
// … user completes flow …
valorq.endFlow("wire-transfer");
A short example (iOS / Swift)
import ValorQ
let valorq = try ValorQ.shared.configure(
tenantId: Bundle.main.valorqTenant,
mode: .sdkOnly
)
valorq.onRiskChange { verdict in
switch verdict.tier {
case .block: flowCoordinator.abort(reason: .highRisk)
case .review: flowCoordinator.requireStepUp()
case .clear: break
}
}
// SwiftUI integration
TransferScreen()
.valorqFlow("wire-transfer")
The integration surface is intentionally small — configure once, subscribe once, wrap flows. Most teams land on this shape within a sprint.
How ValorQ compares to alternatives
Behavioral biometrics is a real category and the vendors in it are not interchangeable. A fair reading:
- BioCatch is the incumbent premium option. Deep install base at large banks, strong track record on desktop banking flows, cloud-based architecture. If you are already running their platform and it fits your compliance posture, ValorQ is not trying to displace it. Where ValorQ wins: mobile-first surfaces, teams that need on-device processing to reduce compliance scope, and teams that want cross-platform consistency they can reason about.
- Sardine approaches fraud from a consortium / AML angle, blending behavioral signals with device and network graph data. Strong for payments and crypto exchanges. ValorQ is narrower and deeper on the pure behavioral dimension, and lighter to integrate for teams that already have a fraud stack.
- Device fingerprinting (Fingerprint, Iovation, and similar) is not the same category — it identifies a device across sessions but does not model how a user behaves within a session. ValorQ is complementary to device fingerprinting, not an alternative to it.
The right question is not “which vendor is best” but “which architecture matches our compliance posture and where do we need signal we don't have today.” ValorQ is architected for teams that need on-device processing, cross-platform consistency, and a statistically robust scoring model. If those constraints match yours, we're a good conversation.
Quick comparison
A rough shape-of-fit table. Every deployment is different; treat this as a starting point for a real conversation, not a scorecard.
| Dimension | ValorQ | Cloud-scored vendors | Device fingerprinting |
|---|
| Where scoring happens | On-device by default | Vendor backend | Client + vendor lookup |
| Data egress required | Zero in Model 1 | Full behavioral stream | Device identifiers |
| Verdict latency | Immediate (local) | Network round-trip | Network round-trip |
| Cross-platform baseline | Unified model, per-platform baselines | Varies by vendor | Device-level, not user-level |
| Scoring model | Statistically robust (MAD z-score), auditable | Often ML, less transparent | Rule + reputation |
| Best fit for | Regulated mobile-first teams | Established desktop-heavy banks | Complementary layer |
The most useful way to read this: behavioral biometrics is not a binary buy-or-don't decision. Most mature fraud stacks end up layering behavioral signal on top of device fingerprinting and transaction monitoring, because each catches a different attack pattern. ValorQ is designed to be that behavioral layer without forcing the rest of your stack to change.
Getting started
See ValorQ running on your stack.
Start with Model 1 — no backend required. We'll walk through signals, scoring tiers, and integration paths for your specific platform mix.
Request SDK access