Asked by every serious buyer.
Answered plainly.

No. The SDK never reads what a user types — only timing and motion patterns, reduced in the browser to a small set of timing statistics (session summaries plus per-key timing averages under opaque, device-salted labels) before anything is transmitted. Device identity is a random, locally-generated ID hashed with SHA-256 before it leaves the device. No names, no emails, no IMEI, no fingerprinting.

The raw behavior never leaves the device, so there is nothing raw to reverse. What does move — summary statistics and scores — carries calibrated differential-privacy noise, which makes reconstructing an individual's data from outputs statistically implausible. This is a mathematical property of the outputs, not a policy we ask you to trust.

Fingerprinting identifies a device across sites, typically without consent — it's a tracking technology, and regulators treat it as one. Lava Sense verifies that the person behind an already-authenticated session behaves like the account owner, inside one application, with consent. It answers "is this them?", never "who is this?".

You call DELETE /v1/devices/{device_id}/baseline and the enrolled behavioral profile is gone. There is nothing else of theirs to delete, because nothing else of theirs was ever stored.

The browser SDK is a single ~4 KB JavaScript file with no dependencies. Capture is passive event listening; feature reduction is a few hundred arithmetic operations. Verdict calls are a single small JSON round-trip, with server-side scoring measured in milliseconds (the response includes processing_time_ms so you can see it).

The verdict model is deliberately three-state: uncertainty resolves to STEP_UP (ask for one more factor), and BLOCK is reserved for high-confidence anomalies. Low-risk sessions continuously refine the baseline, so a customer whose behavior drifts — a new keyboard, an injured hand, a borrowed laptop — converges back rather than being locked out.

You keep control: the verdict is advice to your server, and your risk policy decides what each state triggers.

A device's baseline is learned over its first few sessions (three by default, configurable per deployment). During enrollment the verdict is ALLOW and responses are labelled mode: "enrolling", so you always know which regime you're in.

The browser SDK targets all evergreen browsers (it relies on standard events, crypto.subtle, and fetch). SIM-level signals — such as real SIM-swap detection — require the mobile SDK, which is part of the design-partner roadmap; the API already reserves the sim_status field for it.

Yes — the live demo runs the real scoring engine. Type a few sessions to enroll, then type differently (or hand the keyboard to someone else) and watch the risk score respond. The API also serves an interactive OpenAPI explorer at /docs on the API host.

The architecture is built to the Nigeria Data Protection Act 2023 and the GAID 2025 implementation guidance: data minimization by construction, explicit consent surfaces, local processing, and right to erasure as a first-class API call. Our DPA and records of processing are available to design partners during onboarding.

Yes. The same properties that satisfy the NDPA — minimization, purpose limitation, erasure, no raw-data movement — are what GDPR Article 25 (data protection by design) asks for. European partners can consume scores without importing personal data, because no personal data is in the scores.

Raw behavioral processing happens on the user's device — it is never in transit, so residency questions don't arise for it. The statistical baselines the API holds contain no raw behavior and no identity; hosting region is agreed per deployment for partners with residency requirements.

Behavioral Security is priced per scored session with volume tiers; clean-room engagements (Share Without Sharing) are priced per collaboration; Language Intelligence is licensed per device or per seat. Design partners get preferential terms in exchange for shaping the roadmap. Specifics: partnerships@cleanlava.com.

A typical Behavioral Security pilot runs on one high-risk flow (login or transfer) in shadow mode — scoring real sessions without acting on the verdicts — so your fraud team can measure the signal against known outcomes before it touches a customer. Weeks, not quarters.

Design partners get a shared channel with the engineering team and committed response times for production issues. Everyone can reach support@cleanlava.com. Details on the support page.