DB
Back homeUse case

Fraud & risk

Score events against current state on the write path, with reads that always reflect the writes that just landed.

The problem

Why this is hard today

Fraud and risk scoring live or die on a single property: the state you score against must include the event you are scoring. A velocity check that reads a rolling count which does not yet include the current transaction is not a check — it is a delay before the fraud clears.

Most stacks introduce exactly that delay: the write goes to one system, the feature store updates asynchronously, and the scorer reads a stale snapshot. The gap is small in milliseconds and enormous in dollars.

What risk needs is read-your-writes freshness on per-entity state, and counts that are exact — because a threshold compared against an approximate count is a threshold you cannot defend in an audit.

Architecture

How NYXDB does it

Per-entity state lives in keyed and attribute tables that are updated on the write path; a scoring read sees the write that just landed, and the counts behind it are exact.

  1. 01

    Write + update

    A transaction appends and updates per-entity rolling state in one committed step.

  2. 02

    Read-your-writes

    The next read reflects that write — no async feature-store lag window.

  3. 03

    Score

    The scorer reads current state and exact counts to decide.

  4. 04

    Audit

    Historical and AS OF reads reconstruct exactly what state a decision saw.

Real SQL

In practice

Per-account rolling state — keyed table
CREATE TABLE account_state (
account_id String NOT NULL,
tx_count_1h UInt64,
PRIMARY KEY (account_id)
) DELTA (keep = 'latest');
Velocity check against fresh state
SELECT account_id, tx_count_1h,
tx_count_1h > 25 AS flagged
FROM account_state
WHERE account_id = 'acct-1';
Exact flagged-account count
SELECT count() FROM account_state WHERE tx_count_1h > 25;

Every statement follows the engine’s own test SQL shapes. See the SQL reference for full syntax.

Capabilities

What you get

Read-your-writes

No stale window between the write and the scoring read.

Exact counts

Thresholds compared against exact counts, not estimates.

Per-entity state

Keyed and attribute tables hold rolling state per account.

Auditable history

AS OF reconstructs the exact state a decision saw.

Streaming scores

STREAM SELECT drives real-time scoring off the write path.

Low-latency reads

Current-state reads are point reads, not scans.

Proof

Measured where it counts

read-your-writes

no stale scoring window

core semantics

exact

counts behind every threshold

keyed collapse (ADR-078)

sub-msTODO-verify

scoring read latency class

placeholder — not yet substantiated

Figures marked TODO-verify are placeholders pending a published, reproducible benchmark; substantiated numbers cite their source.

Score against state that includes the event

Run a node and wire a read-your-writes velocity check.