GateBacktest: policy backtesting on your history
Run a candidate policy over your last N days before activating it: what changes, which cases open or close.
Start free sandboxTalk to us50 screenings a month free, no card.
On this page
GateBacktest in simple terms
Before you change a rule, GateBacktest runs the new version over your past months of decisions and tells you what would have been different: how many more reviews, how many fewer, which customers.
You see the cost of a change before it touches a real customer, and you have the numbers on file for why you made it.
IN EVERYDAY TERMSThink of a flight simulator for your compliance rules: you try the new setting on past flights before carrying real passengers.
What it does
GateBacktest runs a candidate policy over your own stored history (by default the last 90 days, up to 2,000 screenings) and reports what would change: how many decisions stay the same, how many move and in which direction, how many cases would be opened or avoided, how many new blocks, and a sample of the individual screenings that flip, with the rule that fired.
It uses the same pure evaluator that GateReplay uses, over stored signals, coverage and receipt inputs. No provider is queried again.
The rule-performance view (console Tune page, GET /api/v1/reports/rules) shows, per rule, how often it fired, what reviewers did with the cases it opened and how many outcomes it changed, so you know which rule to backtest before you touch a threshold.
Why a broker needs it
Compliance officers tighten rules after an incident and loosen them after complaints, usually without seeing the effect first. A backtest shows the trade-off in numbers before the change goes live, and gives you a written reason for the policy version you activated, which is what an examiner asks for when a threshold moved.
How it works
In the console, open Policy, edit the candidate, and run the backtest. The result lists transitions ("REVIEW→ALLOW: 41"), counts of would-open, would-avoid and would-block, a breakdown by new decision, and the changed samples. Screenings whose receipts predate replay support are counted as partial inputs rather than guessed. Activating the candidate creates a new immutable policy version; the old one remains available for replay.
What it does not do
A backtest only sees what was recorded at the time: signals a rule did not exist to emit then cannot be re-derived now, and processor or behaviour data you did not send is absent. It says what your policy would have decided on that evidence, not what the outcome of the case would have been.
Where it lives in the docs: /docs#replay