Score a transaction

Describe one payment and the model says how likely it is to be fraud, with its reasons. Two models look at it: one that learnt what normal payments look like and flags what it cannot explain, and one that learnt what known fraud looks like from labelled examples.

Which bank's idea of normal Each training dataset counts as a bank with its own habits. Pick the one this payment resembles, or generic for a bank the model has never seen. Alert budget How many honest payments you accept flagging by mistake. The flagging threshold is set so that exactly this share of legitimate traffic lands above it; a bigger budget catches more fraud at the price of more false alarms. Model version Which version of the model judges this payment. The newest is the default and the best; the earlier ones are kept so you can see how much each step of the development changed the answer. Compare every version score it on every version, side by side Shows every version's verdict side by side under the main one. Each adds a fraction of a second. Fraud labels arrive within How quickly a bank finds out a payment was fraud (chargebacks take weeks). The model only uses fraud history it would have known at the time: set this to a month and it stops reading last week's confirmed fraud at this merchant, card or device.

Load a real example the model never trained on:

Customer history (the customer's previous payments)

The newest model judges a payment against this customer's own habits. Paste their previous payments as JSON, oldest first — a list of {"features": {...same field names...}, "secs_before": 3600} (or "ts" in epoch seconds). On your own installation you can instead give a customer id and the server remembers what it scores for that id; the public site keeps nothing.

previous transactions (json) customer id

Device details (what the device model sees)

What the browser or app reports about the device; a small model judges how risky the device looks on its own. Keys: os, browser, device_type, screen, session_length_min, keep_alive, phone_valid, email_domain, recipient_email_domain, name_email_similarity, account_age_days, foreign. Fields set in the form win.

device (json)

Text on the payment (what the text models read)

Free text that came with the payment: url (judged by a model trained on malicious links), description / memo / message (one trained on scam postings), profile / bio (one trained on fake profiles). Each adds its own evidence to the verdict. None of the payment datasets carried text, so this never changed a reported number.

text (json)

How the customer used the device (mouse, keystrokes, touch, motion)

Raw events from the session, which a set of models trained on public behaviour data compares with how this customer usually moves and types: mouse rows [t, x, y, kind], keystroke rows [t, key, down|up], touch rows [t, x, y, pressure, size, action], motion rows [t, x, y, z]. On your own installation a customer id lets the server build that customer's profile from their earlier sessions; the first session only enrols.

session (json)

Score a whole spreadsheet instead

A CSV file using the field names from the How it works page (any subset). Every row gets a probability, a percentile and a flag at the alert budget above. If the file has an is_fraud column you also get the accuracy (AUROC and recall) on your own data.

Score a transaction

Training data

Which fields each dataset has

Rebuild

Model & training

The six versions

Train on this machine

Compute & remote GPU

Should this run here?

The app's ssh key

Remote server

1. Provision

2. Launch training

3. Watch & collect