Everything the platform consumes, how to get your data in, and where each control that shapes surveillance behavior lives. The API documentation covers the programmatic surface in detail.
| Module | What it does |
|---|---|
| Pre-Trade Risk | Gateway guardrails (maker-checker), kill switches, dynamic restricted lists |
| KYC & Graph | Entity resolution: joins accounts sharing identity attributes into operator clusters |
| Context Engine | World-event catalysts (news, injuries, wires) aligned to market timelines |
| Forensics T+1 | Daily settlement scan: god-mode outliers, MNPI, spoofing, wash, parity, pump-and-reversal, cluster limits |
| On-Chain | Wallet screening and cluster inflow dispositions for crypto-settled venues |
| Reporting & Audit | Part 16/17 files, SAR drafts, CCO inputs, hash-chained audit packages with four-eyes release |
Templates: trades · accounts/KYC · restricted list — fill these in and upload; the validation report tells you exactly which rows need fixing.
Two paths, one schema, one validation pipeline:
GUI upload — Portal → Ingestion → drop-copy backfill. One CSV, validated row by row; the report shows accepted counts and per-line rejection reasons. Good for historical backfills ("send us 90 days").
Write API — POST /api/v1/events with JSON-lines and an
Idempotency-Key header for continuous feeds. Retries never double-ingest.
kind,ts_ms,market,account,side,px,qty,outcome trade,1200,CHIEFS-WIN-SB,ACCT-1001,buy,0.58,4000, book,1450,CHIEFS-WIN-SB,ACCT-1001,sell,0.61,2500, settlement,86400000,CHIEFS-WIN-SB,ACCT-1001,,,,win
Markets are created by ingestion — the first row referencing a market symbol creates its stream, and every scan, baseline, and replay path picks it up automatically. There is no separate "create market" step.
kind: trade | book | settlement | catalystcatalyst rows mark when news hit the market (the reference point for
pre-catalyst detection); the account column carries the source label
(JSON lines may use a source field), other columns stay empty.
Catalysts can also be recorded manually on the Context Engine screen.ts_ms: integer milliseconds (venue epoch or session-relative — be consistent per market)side: buy | sell for trade/book rows · outcome: win | loss for settlementspx: $0.01–$0.99 binary bounds · qty: positive integerSettlement rows are what power the god-mode profitability grid, computed baselines, and backtests — a trades-only feed limits detection to order-flow patterns.
Related contracts: markets whose symbols share all but
the last hyphen segment (4+ segments, e.g. NFL-KC-PHI-TOTAL and
NFL-KC-PHI-SPREAD) form an event group — correlated-contract detection
flags accounts structured across a group's books. Name related contracts
accordingly.
Portal → Ingestion → account & KYC upload. Each row becomes an account profile (grids, search, account drill-downs) and joins the syndicate graph:
account,identity,funding,device,subnet,address,restricted ACCT-1001,J. Smith (verified retail),Bank ····8812,fp-3a91,,,false ACCT-1002,J. Smith spouse acct,Bank ····8812,,,,false ACCT-2001,QuickTrade LLC,Wire ····0042,fp-77b0,10.4.8.0/29,,false ACCT-3001,Restricted person (league roster),Bank ····5590,,,,true
account and identity are required; everything else is optionalfunding (0.9) and device (0.85) are strong links — either alone joins two accounts into a clusteraddress (0.6) and subnet (0.4) are weak — they join only when corroborated by a second independent link kindrestricted: true marks a restricted person (athletes, officials, insiders) for gateway checksIn the example above, ACCT-1001/1002 share funding (strong → one cluster) and ACCT-2001 stands alone. After each upload the graph rebuilds and re-resolves immediately; human validation on unchanged clusters is preserved.
| Data | Consumed by |
|---|---|
| Trades & order book | Spoofing/wash/parity/pump detectors · DVR replay · pre-catalyst stream detection |
| Settlements | Per-market baselines · god-mode z-scores · watchlist scan · backtests · Part 16 |
| Account identity attributes | Entity resolution · cluster position limits · restricted-person gateway checks |
| Resolved clusters | CP 5 aggregate limits · MNPI ring detection · alert risk scoring · position-limit report |
| Catalysts (world events) | Pre-catalyst accumulation detection on continuous streams |
det_*
rows (god-mode z, spoof ratio, cluster limit) are the live detector parameters. Every
change is maker-checker: propose → a second identity approves → WORM-logged. Proposals
on detector thresholds automatically attach a backtest at the candidate value so the
approver sees what would have fired.name,category,applies_to,effective); every upload is a new
content-hash version and every gateway block cites the version in force.| Role | Can |
|---|---|
| Analyst | Triage, evidence, notes, investigations, ingestion |
| Officer | + dispositions proposals, SAR drafts, guardrail proposals, package requests |
| Supervisor | + approvals (second identity), kill switches, package releases |
| Regulator | Read-only, optionally case-scoped and time-boxed; views are access-logged |
| Admin | Everything + users, API keys, webhooks, tenant settings, backups |
Evidence files, generated reports, and package manifests are stored write-once with SHA-256 recorded at creation; package manifests are additionally chain-hashed (H(n) = sha256(H(n−1) ‖ shaₙ)). Generated series: Part 16 daily products (auto), position-limit exceptions, Part 17 large trader, FinCEN SAR drafts, Part 9 / referral drafts, case files, and CCO annual inputs. Ad-hoc audit packages scope any of it for an exam and release only under four-eyes.
Something unclear or a format we should support? Get in touch · API documentation