From API call to fraud decision in 47ms.

Four stages, each with a measured latency budget. No black box — every millisecond accounted for.

Step-by-step process

STEP 01 — 2ms

Ingest and validate

Your system POSTs to /v1/score with the transaction payload. Required fields: transaction_id, amount, currency, merchant_id, card_fingerprint, device_id, ip_address. Optional fields — user_agent, shipping_address, billing_address, session_id — extend signal depth without changing latency SLA. The ingestion layer validates field types, normalizes currency amounts, and routes to signal workers within 2ms.

POST /v1/score
{
  "transaction_id": "txn_4f91c2",
  "amount": 215.00,
  "currency": "USD",
  "merchant_id": "mer_8821",
  "card_fingerprint": "fp_a3b9",
  "device_id": "dev_cc41",
  "ip_address": "203.0.113.42"
}
STEP 02 — 38ms

Parallel signal compute

Six signal categories fan out to independent compute workers simultaneously. Device fingerprint workers check hardware entropy, canvas hash, and browser anomalies. Velocity workers count transactions across 1h, 6h, 24h windows per card and device. Geo workers check IP reputation, VPN/proxy detection, and physical impossibility flags. All 140+ signals are computed in parallel — the total window is the slowest single category, consistently under 38ms.

DEVICE

fingerprint · entropy · canvas

VELOCITY

1h · 6h · 24h windows

NETWORK

IP rep · VPN · geo velocity

BEHAVIORAL

session drift · nav pattern

IDENTITY

email age · PII composite

HISTORY

chargeback · dispute · drift

STEP 03 — 5ms

Model inference

Signal vectors from all six categories are merged and passed to the inference model. The model outputs a risk score 0–1000, a confidence band (e.g. 0.89), and a ranked list of contributing_signals with their weights. Thresholds are applied: below 400 is ALLOW, 400–699 is REVIEW, 700+ is BLOCK. On Growth+ plans, thresholds can be set per merchant_id to tune for your fraud/friction tradeoff.

RISK SCORE

742

BLOCK

confidence: 0.91

STEP 04 — 2ms

Response returned

The JSON response includes score, label, confidence, latency_ms, contributing_signals[], and thresholds_applied. Your system acts on label in real time — block the transaction, queue it for manual review, or allow it without friction. The response format is versioned; field additions are non-breaking. Average P50 latency is 44ms; P99 is under 80ms.

RESPONSE TIMES

P50
44ms
P75
52ms
P99
78ms

47ms total. Every millisecond explained.

Latency is a hard constraint for payment systems — a decision that arrives after authorization has no value. Here is exactly where the time goes.

Total median 47ms

Outcomes flow back. Signal weights sharpen.

The scoring model is not static. Chargebacks confirmed as fraud, and transactions you mark as false positives, feed back through the /v1/feedback endpoint. Signal weights update daily. The model learns your transaction mix — not an anonymous pool of other customers' data. Txnworks does not use your labeled outcomes to train a shared model. Your feedback data stays in your tenant namespace.

See the full product architecture