ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →

Risk-based login: a score from 0 to 100 decides allow, second factor or block

Each login is scored on location, impossible travel, device, velocity, time, method and account age. Low scores pass, middling ones need a second factor, high ones are blocked. Failures are limited three ways.

A password that is correct is not proof of the person. This release scores each login on what else is known and lets the score decide how much more to ask.

The score

  • Seven signals Location familiarity and impossible travel weigh a quarter each, device familiarity and login velocity 0.15 each, with time of day, authentication method and account maturity completing the score.
  • Three outcomes From 0 to 29 the login is allowed, from 30 to 59 a second factor is required, above that it is blocked. A risk-forced second factor ignores the remembered-device cookie on purpose.
  • Explained The assessment renders a signal-by-signal breakdown of score, weight and reason for the audit, and locations read as region, country and city.

Around it

  • Three-dimensional limits Failed logins are tracked per account, per IP and per pair, which catches distributed brute force and credential stuffing that a pair-only limiter misses.
  • Alerts High-risk events mail the company's security address as a branded, localised template rendered from the database.

The scoring landed in March and the explanations in July. Together they turn a yes-or-no login into a judgement an auditor can read.