Phase 1 of 6
Scoping & Strategy Profile
Define the strategy family, latency envelope, execution venues, capital exposure, and regulatory regime that together dictate every architectural decision downstream.
0/8
Phase Progress
Required Recommended Optional Open-Source Proprietary Trinidy
Strategy Family & Latency Envelope
Identify algorithmic strategy families in scope
Why This Matters
Strategy family, not asset class, is the primary determinant of the inference architecture. Market making and HFT latency arbitrage live and die at 100–500ns tick-to-trade and require FPGA or ASIC — JPMorgan LOXM at sub-10μs is RL on co-located GPU clusters within 10m of the matching engine, while VWAP/TWAP execution algos survive on CPU at 1–10μs. Mixing strategy families onto a single inference fabric without separating their latency classes is the most common architectural miss, and it forces the slowest strategy to define everyone's ceiling.
Note prompts — click to add
+ Which of our strategies generate the majority of P&L, and what is their tick-to-trade budget?+ Do we have a latency-tiered architecture today, or does one shared fabric serve market-making and execution algos?+ Which strategies are currently blocked from going live because of inference latency?
Required
Confirm which strategy archetypes the inference stack must support.
Select all that apply
Market making (quote both sides, capture spread)
Statistical arbitrage (cross-sectional / pairs / basket)
Execution algorithms (VWAP / TWAP / POV / implementation shortfall)
Smart order routing (SOR) across venues
RL-based execution optimization (LOXM-style)
Directional alpha (LSTM / Transformer signal generation)
HFT latency arbitrage (tick-to-trade critical)
Cross-asset / cross-venue spread trading
Event-driven / news-reactive strategies
required
✓ saved
Define tick-to-trade latency budget
Why This Matters
The 2024 Exegy + AMD Alveo UL3422 STAC-T0 world record is 13.9ns tick-to-trade, and the AMD Alveo UL3422 transceiver alone is sub-3ns — these are the numbers market-making desks are measured against. FPGAs outperform high-end CPUs by up to 1,000× for latency-critical order routing, and a 7μs vs. 15μs gap is the difference between capturing spread and being adversely selected on every trade. A latency budget set without reference to published competitor benchmarks is a budget set against a straw man.
Note prompts — click to add
+ What is our measured P99 tick-to-trade today, and how far is it from the relevant FPGA / GPU benchmark for our strategy class?+ Are our slowest hops CPU compute, kernel networking, PCIe, or exchange gateway, and which one can we actually move?+ Do we have deterministic P99.9 — or does jitter blow the budget even when the average is fine?
Required
Select the P99 tick-to-trade envelope the inference path must hold at peak load.
Single choice
< 100ns tick-to-trade (ASIC-class, world-record tier)
100–500ns (FPGA + kernel bypass — production HFT)
1–10μs (co-located GPU / optimized CPU — execution RL, market making)
10–100μs (co-located software — stat arb, SOR)
100μs – 1ms (near-colo or cross-venue coordination)
> 1ms (execution algos tolerant of software latency)
requirededgetrinidy
TrinidyCloud inter-DC RTT adds 1–3ms minimum — 1,000× the 7μs competitive floor Citadel Securities targets. Trinidy deploys inside the exchange colocation perimeter with FPGA (100–500ns) and GPU (sub-10μs) on a single fabric — the only physically viable path for tick-to-trade at HFT budgets.
✓ saved
Map execution venues in scope
Why This Matters
Each venue has a distinct matching-engine idiosyncrasy that the model must encode as a feature — IEX's deterministic 350μs speed bump neutralizes pure latency arbitrage on that venue, while NYSE Pillar and NASDAQ INET have measurably different queue dynamics. A single SOR that ignores venue-level microstructure ends up routing into toxic flow at the wrong venues. The venue list also drives the colocation bill: Citadel Securities spends roughly $14M/year on colocation at NYSE, CME, and NASDAQ alone, and NASDAQ incremental colo fees start at $2.5M on a 3-year commitment.
Note prompts — click to add
+ Which venues have we measured as most toxic for our flow, and does the model avoid them when predicted adverse selection is high?+ For cross-venue strategies, are we funding redundant colo at every venue that matters, or accepting a latency handicap at some?+ Have we modeled the IEX speed bump as a feature, or does our signal assume all venues are latency-linear?
Required
Inventory the matching engines, dark pools, and ECNs the model must route to.
Select all that apply
NYSE / NYSE Arca
NASDAQ (all tape) — INET matching engine
CBOE BZX / BYX / EDGX / EDGA
IEX (intentional 350μs speed bump)
CME Group (futures / rates / commodities)
ICE Futures US / EU
LSE / Euronext / Deutsche Börse (Xetra)
Tokyo Stock Exchange / SGX / HKEX
Dark pools / block venues (Liquidnet, ITG POSIT, Level ATS)
Internal crossing network
Crypto venues (Coinbase, Binance, CME crypto futures)
required
✓ saved
Define capital at risk and per-strategy loss budget
Why This Matters
Capital at risk is the input to every pre-trade risk check under SEC Rule 15c3-5 and MiFID II Article 17 — the inference stack must enforce per-order, per-strategy, per-symbol, and per-desk limits before every order leaves the firm, at sub-microsecond latency. An inference platform that can score at 7μs but cannot run the 15c3-5 check at the same latency forces either a rule violation or a latency penalty that erases the alpha. The sizing of the loss budget also determines whether kill switches can be coarse (desk-wide) or must be fine-grained (per-strategy, per-symbol).
Note prompts — click to add
+ Where do pre-trade risk checks execute today — on the same FPGA as the scoring model, or on a separate slower path?+ What is the measured latency of our 15c3-5 gate, and is it inside or outside our tick-to-trade budget?+ Do we have per-strategy capital limits that the model is aware of, or only a global desk limit that the model cannot see?
Required
Quantify maximum capital deployed and loss tolerance that the inference stack governs.
Single choice
< $10M notional intraday capital (desk-level)
$10M – $100M intraday (mid-tier prop / bank desk)
$100M – $1B intraday (major bank / HFT firm)
> $1B intraday (Citadel / Virtu / Jump scale)
Capital is venue / strategy segregated — mixed
required
✓ saved
Identify applicable regulatory regimes
Why This Matters
The algorithmic trading regulatory surface is cumulative, not menu-pick — a U.S. bank running strategies that touch European venues is simultaneously under SEC 15c3-5, FINRA 3110, Reg SCI, MiFID II Art. 17, MAR, and SR 11-7, and each has distinct documentation, kill-switch, and self-assessment obligations. MiFID II Article 4(1)(40) defines HFT as 2 messages/sec per instrument or 4 messages/sec across a venue — crossing that threshold triggers annual conformance testing and algorithm registration with the NCA within 5 days on request. Treating any of these as someone else's problem is how enforcement starts.
Note prompts — click to add
+ Do we meet the MiFID II HFT definition on any EU venue, and have we notified the relevant NCAs?+ Who owns the 15c3-5 attestation today, and is the attested architecture the one actually in production?+ For each strategy, which regime is the binding constraint, and is its documentation current?
Required
Select every regime whose algorithmic trading rules govern this stack.
Select all that apply
SEC Rule 15c3-5 (U.S. market access rule — pre-trade risk)
FINRA Rule 3110 (supervision of algorithmic trading)
FINRA Rule 5270 / 5320 (front-running / trading ahead)
SEC Reg SCI (systems compliance and integrity)
MiFID II Article 17 (algorithmic trading systems)
MiFID II RTS 6 (annual self-assessment + kill switches)
EU MAR / MAD II (market abuse, spoofing, layering)
UK FCA SYSC 4 / 7 + MAR (post-Brexit regime)
MAS SFA / Notice on Algorithmic Trading (Singapore)
HKEX / SFC algorithmic trading requirements
ASIC RG 241 (Australia algorithmic trading)
Federal Reserve SR 11-7 (bank model risk management)
required
✓ saved
Specify deployment topology for the inference plane
Why This Matters
Deployment topology is the ceiling on every latency and compliance decision downstream. Exchange colocation is mandatory for competitive HFT latency, and Equinix NY4 / LD4 / TY3 are the de-facto proximity anchors for U.S., European, and Asian equities respectively. The colocation services market is $84B in 2024 and projected $204B by 2030 — the spend is real but it is the only architecture that survives the physics. A hybrid that keeps the critical path in colo while pushing heavier RL sub-models to private cloud is viable, but only with explicit latency gates at the boundary.
Note prompts — click to add
+ Are we at the right colo site for our most-traded venues, or has our venue mix drifted away from our original colo footprint?+ Do we have dedicated cage space, or are we in shared-tenant infrastructure where a noisy neighbor can breach our SLA?+ What is our measured network latency to the matching engine — and is it fiber, microwave, or both?
Required
Select the physical deployment target for the scoring and order-generation stack.
Single choice
Exchange colocation cage (NYSE / NASDAQ / CME / LSE)
Proximity hosting (Equinix NY4 / LD4 / TY3 — adjacent data centers)
Wireless / microwave tower at matching engine campus
Regional bank data center + colo cross-connects
Private cloud / VPC (non-HFT strategies only)
Hybrid — FPGA path in colo, heavier sub-models in private cloud
requirededgetrinidy
TrinidyFor sub-10μs execution and MiFID II Article 17 kill-switch SLAs, cloud is physically and regulatorily excluded. Trinidy deploys inside the exchange colocation perimeter on dedicated hardware — no shared tenancy, no hypervisor jitter, no cross-tenant side-channel surface.
✓ saved
Define kill-switch activation surface
Why This Matters
MiFID II and MAS require kill-switch response in the same order of magnitude as order submission itself — "cancel all open orders immediately" is the operational phrasing, and NCA examinations explicitly test timing. A kill path that has to round-trip through a cloud API is a kill path that does not meet the standard. Granularity matters too: a global desk kill on a spoofing alarm closes down legitimate alpha-generating strategies that had nothing to do with the trigger, so per-strategy and per-symbol kills are a material risk-management capability, not a nice-to-have.
Note prompts — click to add
+ Where does our kill-switch path execute, and what is its measured activation-to-cancel latency?+ Have we fire-drilled the kill switch in production in the last 12 months under NCA or internal audit observation?+ Can we kill one strategy without killing the desk, and is that granularity in the kill-switch test protocol?
Required
Specify the granularity and latency budget of the mandated kill-switch path.
Select all that apply
Global desk kill (all orders, all strategies, all venues)
Per-strategy kill
Per-venue kill
Per-symbol kill
Per-trader kill (supervisory override)
Automated price-collar / fat-finger check
Automated message-rate throttle (pre-regulatory floor)
Manual dead-man switch in trading room
requirededgetrinidy
TrinidyMiFID II Article 17 requires sub-microsecond automated kill-switch response. Trinidy executes the kill path on the same FPGA fabric as the order-generation path — no OS, no network hop, no human in the loop for the panic-stop.
✓ saved
Strategy IP isolation and model sovereignty requirements
Why This Matters
Algorithmic trading strategies are among the most sensitive IP a financial firm owns — a $5M+ multi-year FPGA engineering investment is worth zero the day it leaks. Shared cloud inference creates multiple attack surfaces that are hard to close: provider telemetry, co-tenant cache timing, hypervisor metadata, and even the inference provider's own logging. The MiFID II algorithm-registration obligation also requires a firm-held description of strategies and risk controls — which is incompatible with inference substrates that treat model weights as vendor-observable.
Note prompts — click to add
+ Is our inference silicon dedicated to our firm, or shared tenancy with cache/timing exposure to other workloads?+ Does our training pipeline leave the firm's perimeter for any step — including managed ML platforms or vendor foundation models?+ Who at a cloud or inference vendor has administrative access to our model artifacts, and have we accepted that risk?
Required
Document the sensitivity of models, signals, and order flow — and who must never see them.
Select all that apply
Model weights must never leave firm perimeter
Training data (order flow) must never leave firm
Inference silicon must be single-tenant
No cloud-provider telemetry on the inference path
Model-version metadata isolated from venue / counterparty
Separation from other firm's strategies within the same venue
Air-gapped training environment
requiredtrinidy
TrinidyProprietary models and order flow are alpha. Trinidy's dedicated inference infrastructure ensures the model never shares silicon with another firm — no side-channel surface, no cloud provider telemetry, no co-tenant inference risk.
✓ saved