Public sandbox
Run transparent synthetic assessments and inspect every scoring input and result.
Interactive workbench
The workbench shows the complete synthetic history and assessment sequence before sending it. Each response includes the normalized request, stable request fingerprint, raw signals, weighted contributions, evidence, and decisions.
An identical payload should return identical scores. That is deterministic scoring, not a hardcoded response. Only the run ID, timestamps, and latency may vary.
Request limits
history: up to 12 events before scoring, each with an outcome ofunknown,legitimate, orconfirmed_fraud.assessments: 1–10 uniquely identified events in ascendingoffsetSecondsorder.- Body: at most 32 KB with no unknown properties.
Allowed assessment data is limited to synthetic transaction, user, device, payment, and shipping aliases; documentation-reserved IP addresses; amount and currency; country, card, timezone, and IP-geography fields. Aliases must start with demo_. Email, phone, customer name, profile URL, metadata, routable IP addresses, and unrestricted identifiers are rejected.
What changes the score
| Input | Evidence affected | | --- | --- | | Timing and repeated IP/device aliases | Velocity counts, burst ratio, and z-score. | | Shared device, IP, payment, or BIN | One-hop and two-hop graph topology. | | Shared indicators from confirmed-fraud history only | Fraud similarity and fraud-neighbour floors. | | Country, card type, timezone, amount, and coordinates | Contextual contributions. |
Clean shared history can create graph connections but never fraud similarity. Some valid fields, such as labels and currency, provide context without directly changing the score.
Reading a result
The four raw signals use production weights: graph 35%, velocity 25%, similarity 15%, and contextual 25%. Their displayed weighted contributions reconcile to scores.final.
The default hybrid policy allows scores through 30, reviews scores above 30 through 75, and blocks scores above 75. A direct confirmed-fraud neighbour can apply a minimum review action; recommendedAction remains the score-based result.
Each step exposes:
- its normalized assessment and final decision;
- raw and weighted signal values;
- velocity counts, baseline, z-score, burst ratio, and outlier state;
- graph neighbours, fraud neighbours, matched indicators, scale, and safety floor;
- similarity denominator and confirmed-fraud matches;
- contextual contribution names and values;
- thresholds and reason codes.
Use Risk Scores for response semantics and Assess Transactions for the authenticated production contract.
Privacy and reliability
The editor accepts constrained synthetic aliases only. The backend stores no run, creates no tenant assessment, and returns no-store. Up to 10 results remain in page memory until refresh or navigation; they are not placed in local storage or transmitted as run history.
Requests are rate limited. When configured, Cloudflare Turnstile must verify each run. Validation returns field errors; 403 identifies verification failure; 429 identifies rate limiting; proxy and upstream failures remain visible in the workbench.
What is deliberately excluded
The sandbox reuses the deterministic contextual, graph, velocity, weighted-aggregation, and policy-decision calculators over request-local synthetic state. It excludes tenant graph data, Redis history, GDS features, ML inference, custom tenant policy, persistence, usage metering, feedback, threat promotion, and all production writers.
Sandbox output is not a fraud-performance benchmark or a prediction for your traffic. Use an authenticated shadow evaluation before changing production policy.