Glossary
The trading platform uses a lot of jargon: execution algorithms, options Greeks, fixed-income spreads, infrastructure components and observability primitives. This page is the single source of truth for what each term means in VETA specifically. Entries link to the source file when one exists, so “what does this term do in code” is one click away.
The list is generated at build time from docs/site/src/data/glossary.ts. Cross-references are validated during the docs build; a dangling seeAlso will fail the build rather than ship a broken link.
Orders & lifecycle
How an order is described, validated, routed, filled or rejected.
- EMS— Execution Management System
Fills child orders against the simulated market, picks venue and counterparty, computes fees, publishes orders.filled and fix.execution.
The EMS is where execution actually happens. It consumes orders.child from algos (or orders.routed for direct lit orders), routes to a simulated venue (XNAS, XNYS, ARCX, dark pool), assigns a counterparty MPID, sets the liquidity flag (MAKER/TAKER/CROSS), computes the fill price plus market impact, and applies SEC §31, FINRA TAF and commission. The fill is published to orders.filled and a FIX 4.4 execution report goes to fix.execution.
- FOK— Fill Or Kill
Order time-in-force that requires the entire quantity to fill immediately or cancel; partial fills are not allowed.
- IOC— Immediate Or Cancel
Order time-in-force where any unfilled portion is cancelled immediately rather than resting on the book.
- Limit order
An order to buy or sell at no worse than a specified price. Crosses the book only if a counterparty is willing to meet that price.
- Market order
An order to buy or sell at the best currently-available price. Crosses immediately, with no price guarantee.
- OMS— Order Management System
Validates orders against per-user limits, derives the desk, and routes to an algo or directly to the EMS.
The OMS is the gateway between user intent and execution. It runs the role check, the kill-switch check, instrument-derived desk validation, strategy access, quantity-versus-limit, notional-versus-daily-limit, and finally calls the risk engine. If everything passes it publishes orders.submitted and orders.routed; the matching algo (or EMS for direct lit orders) picks up the routed message.
- TIF— Time In Force
How long an order remains active. Common values: DAY, GTC (good till cancelled), IOC, FOK.
Execution & algorithms
Algos, child orders, slicing strategies, venue routing.
- Arrival Price
Algo that targets the price observed at order arrival, adjusting urgency to minimise slippage versus that decision price.
- Child order
A slice produced by an algo from a parent order. Algos publish child orders on orders.child; the EMS fills them.
- Dark pool
Off-exchange matching venue where pre-trade quotes are not displayed. Used for large blocks to avoid moving the visible market.
The platform's dark pool requires the order to have qty ≥ 10,000 and the user to have dark_pool_access=true. The OMS sets destinationVenue=DARK1 on the routed order and the EMS routes to the dark-pool matching engine.
- Deterministic replay
Property of a system where the same inputs produce the same outputs every time. The market simulator's seeded PRNG (mulberry32) plus immutable risk-config versioning gives VETA full deterministic replay.
- Iceberg
Algo that shows only a small visible quantity at a time and refills it on each fill until the total quantity is exhausted.
- IS— Implementation Shortfall
Algo that uses geometric decay to front-load volume early and minimise opportunity cost. Higher riskAversion → faster decay.
- Liquidity flag
MAKER means you posted resting liquidity; TAKER means you crossed it; CROSS means a self-trade. Drives venue rebates and fees.
- Parent order
The user-submitted order that an algo divides into child slices.
- POV— Percent Of Volume
Algo that participates at a configurable percentage of live market volume per tick.
- RTS 6— Regulatory Technical Standards 6 (MiFID II)
EU/UK regulation governing organisational requirements for investment firms doing algorithmic trading. Mandates pre-trade risk controls, kill-switch, conformance testing, message-rate limits, and annual self-assessment.
VETA is a simulator and isn't subject to RTS 6, but the data shapes used for risk-config versioning, scenarios and audit-trail retention are deliberately what RTS 6 would expect. That keeps the codebase from having to be torn up if the platform ever moved towards a real authorisation.
- Scenario
Saved description of a single trade — symbol, side, qty, price, strategy plus a numeric seed — that can be replayed deterministically.
A scenario binds a market-sim seed to an order spec so re-running the saved row reproduces the same fills. Used to detect algo regressions across releases and as the data shape that would back RTS 6 conformance testing if the platform were ever production-bound.
- Slippage
Difference between the price expected at order arrival and the volume-weighted execution price actually achieved.
- Smart Order Router— SOR
The logic that picks which venue a child order goes to. VETA has two SOR modes: an EMS-level weighted-random pick across 7 simulated US venues (default for every algo except SNIPER), and SNIPER's best-effective-price selection across the top N venues simultaneously. Spread and depth multipliers per venue drive realistic fill behaviour.
- Sniper
Aggressive algo designed for low-latency crossing. Fires up to maxSlices quickly at price × aggressionPct.
- TWAP— Time-Weighted Average Price
Algo that splits a parent order into equal slices spread evenly over a duration. Targets the time-weighted average price.
- Venue
Where an order trades. The platform simulates XNAS (Nasdaq), XNYS (NYSE), ARCX (Arca), DARK1 (dark pool), and OTC for derivatives.
- VWAP— Volume-Weighted Average Price
Algo that weights child slices by the historical volume profile so each slice trades against its proportional share of the day's liquidity.
Pre-trade risk
Checks the risk engine performs before an order leaves the OMS.
- ADV— Average Daily Volume
Rolling average traded volume per symbol, used as the denominator for the 'order size vs ADV' risk check.
- Fat-finger price collar
Reject orders whose limit price is more than N% away from the current mid — defends against typo prices.
- Kill switch
Emergency mechanism to cancel and block live orders by scope: all, by user, by algo, by symbol, or by venue. Every action is logged.
- Risk config version
Each change to risk-engine thresholds appends a row to risk.config_versions. Every /check response carries riskConfigVersion: <id> so a past decision can be reconstructed against the exact thresholds that were live when it ran.
- Risk Engine
Synchronous pre-trade check that runs before the OMS routes any order. Six rules: fat-finger, duplicate, max open, self-cross, ADV, rate-limit.
The OMS calls POST /check on the risk-engine for every order. Six checks run in sequence: fat-finger price collar (default 5% from mid), duplicate-order detection (500ms window), max open orders per user (default 50), self-cross prevention, order size versus ADV (default 10% of average daily volume), and rate-limit (default 10 orders/sec). If any check fails the order is rejected with a specific reason code. If the risk-engine is unreachable inside 3s, the order is also rejected — real firms halt trading rather than bypass pre-trade risk.
- Self-cross
A trader's own buy crossing their own sell. Generally prohibited — the risk engine rejects orders that would cross an existing opposite-side resting order from the same user.
Fixed income
Bond pricing, yield curves, RFQ workflow.
- Bond
Debt security paying a coupon (often semi-annual) and returning principal at maturity. Priced via discounted-cash-flow against the yield curve.
- CCP— Central Counterparty
Clearing-house that interposes itself between buyer and seller, guaranteeing settlement and managing counterparty risk via margin calls.
- Convexity
Second-order correction to the price-yield relationship that duration alone misses. Positive convexity is good for the holder.
- Duration
First-order sensitivity of a bond's price to a parallel shift in yields. Higher duration ⇒ more interest-rate risk.
- DV01— Dollar Value of a 01
Cash P&L impact of a one-basis-point parallel shift in yields. Standard unit of interest-rate risk on the duration ladder.
- ISIN— International Securities Identification Number
Twelve-character globally-unique identifier for a tradeable security. Used as the bond identifier in RFQ flow.
- Nelson-Siegel
Parametric model that describes a yield curve with four parameters (β₀, β₁, β₂, τ). Used to fit a smooth curve through observed yields.
- RFQ— Request For Quote
Workflow where a buy-side trader asks one or more dealers for a quote on a specific bond, then chooses to execute or pass.
Fixed-income markets are largely RFQ-driven rather than continuous-quote. The user fills the order ticket with instrumentType=bond plus a bondSpec (ISIN, coupon, periods, yield). The OMS derives desk=FI and publishes to orders.fi.rfq instead of orders.routed. The RFQ service handles the negotiation lifecycle. The user executes via POST /rfq/{rfqId}/execute through the gateway.
- Settlement
Final exchange of cash for securities after a trade. The CCP service tracks T+1 settlement queues and per-user margin.
- Spread
Excess yield over a benchmark. The platform computes G-spread (vs Treasury yield), Z-spread (constant spread over the curve), and OAS (option-adjusted spread).
- Yield curve
Plot of bond yield against tenor. The platform fits a Nelson-Siegel curve and exposes both spot and forward rates.
Options & derivatives
Black-Scholes inputs, Greeks, scenarios.
- Black-Scholes
Closed-form option-pricing model. Inputs: spot, strike, time to expiry, vol, risk-free rate. Outputs: theoretical price + Greeks.
- Delta
First-order sensitivity of an option price to spot. ATM call delta ≈ 0.5; deep ITM ≈ 1; deep OTM ≈ 0.
- Gamma
Rate of change of delta with respect to spot. Highest at-the-money near expiry — that's where gamma scalping pays.
- Greeks
Partial derivatives of option price with respect to its inputs. Delta, gamma, theta, vega, rho. The platform's Greeks Surface panel shows them across strikes.
- Monte Carlo
Path-simulation pricing. The platform uses it for the Scenario Matrix — multiple spot × vol shocks combined.
- Theta
Time decay: how much option value erodes per day with all else held constant. Long options bleed theta; short options collect it.
- Vega
Sensitivity of option price to a 1-volatility-point change. Long vega ⇒ profits when implied vol rises.
- Volatility surface
Implied vol as a function of strike and expiry. The platform fits a SABR-inspired smile per expiry.
Market data
Tick generation, candle aggregation, alternative data sources.
- Candle / OHLCV
Aggregated tick data for a time bucket. Stores Open, High, Low, Close, Volume. The journal aggregates 1-minute and 5-minute candles, capped at 120 per symbol.
- GBM— Geometric Brownian Motion
Stochastic process used by the market simulator to generate realistic-looking price paths. dS/S = μ dt + σ dW.
- Market Simulator
Generates ~80 S&P 500 instruments at 4 ticks/sec via GBM. Per-symbol vol and beta come from sp500Assets.ts.
- Price Fan
Forward-projection panel: simulates many GBM paths from spot and shows the p5/p25/p50/p75/p95 bands. Useful for risk/scenario discussion.
- Tick
A single price-update event published to the market.ticks topic. The platform emits one tick batch every 250ms covering all symbols.
Intelligence pipeline
Features → signals → recommendations.
- Feature Engine
Computes 7 features per symbol per tick: momentum, relativeVolume, realisedVol, sectorRelativeStrength, eventScore, newsVelocity, sentimentDelta.
- Feature vector
The 7-dimensional snapshot the feature engine produces per symbol. Inputs to the signal engine.
- Recommendation Engine
Filters signals at confidence > 0.6 and emits TradeRecommendation events for the UI. Advisory only — never auto-submits.
- Scenario Engine
REST endpoint that re-scores a feature vector under shocks (e.g. realisedVol -30%) and returns baseline + shocked + delta.
- Signal Engine
Applies admin-configurable weighted scoring to a feature vector to produce a directional signal in [-1, 1].
Infrastructure
Services, message bus, deployment surfaces.
- age
Modern file-encryption tool (X25519 + ChaCha20-Poly1305). VETA's planned recipient format for SOPS — public key in .sops.yaml, private key (mode 600) on the host that needs to decrypt.
Pronounced 'ah-gay'. Designed as a simpler PGP replacement. A keypair is two short text strings; a single SOPS-encrypted file can be encrypted to multiple age public keys (laptop + server + CI), each holding their own private key. Adding/removing recipients is `sops updatekeys`.
- BFF— Backend For Frontend
An API tier shaped specifically for the UI it serves rather than for general-purpose API consumers.
- Bus topic
A named partitioned event stream on Redpanda. The platform uses ~25 topics covering orders, market data, news, intelligence and FIX.
- Compose profile
Docker Compose feature that gates services behind named profiles. VETA uses `trading` for the always-on stack and `loadgen` for the on-demand load generator. Services with no profile are always started.
- FIX— Financial Information eXchange
Industry-standard text protocol for trading and order-status messages. The platform speaks FIX 4.4 against an in-process matching engine.
- FIX Exchange
TCP FIX 4.4 endpoint that runs an in-process matching engine. The EMS connects to it as a client to execute orders.
- Gateway
Single entry point for the browser. Validates the session cookie, proxies HTTP to backend services, fans out bus events over WebSocket.
The Gateway is a BFF (Backend-For-Frontend). The browser only ever talks to the gateway — it does not reach OMS, EMS, journal or any other service directly. On every HTTP request the gateway validates the veta_user cookie via the user-service (cached 10s). On WebSocket, it subscribes to every bus topic the UI cares about and forwards events to connected clients.
- GHCR— GitHub Container Registry
GitHub's OCI image registry. The CI matrix builds one image per service and pushes to ghcr.io/milesburton/veta-trading-platform/<service>:latest on every merge to main.
- Kafka Relay
Subscribes to every Redpanda topic and forwards each event as a JSON line to stdout, where Grafana Alloy tails them into Loki.
- loadgen (Compose profile)
The continuous load generator's profile. Activated by scripts/load.sh on; deactivated by scripts/load.sh off. Defines loadgen-token, loadgen-soak, loadgen-matrix.
- OAuth PKCE— OAuth 2.0 with Proof Key for Code Exchange (RFC 7636)
OAuth flow where the client generates a high-entropy verifier, hashes it as a challenge, sends the challenge with the auth request, and reveals the verifier on token exchange. Defends against intercepted authorisation codes.
VETA's user-service implements PKCE for both the web UI and the load generator's token sidecar. The web UI uses it because there's no client secret in a browser app; the sidecar uses it because the same flow is the easiest path to a session-cookie token.
- Redpanda
Kafka-compatible streaming broker used as VETA's message bus. Lighter than Kafka, drop-in replacement at the protocol level.
- Secret rotation
Replacing a credential with a fresh value before its lifetime expires (or after suspected exposure). VETA does this manually today; SOPS will make it `sops <file>` + redeploy.
- SOPS— Secrets OPerationS
Mozilla CLI that encrypts the values (not the keys) in YAML/JSON/env files. The encrypted file is committed to git; decrypted at deploy time via an age key on the host. No daemon, no DB.
Planned for VETA's secrets consolidation (replaces the static .env.loadgen, hardcoded OAUTH2_SHARED_SECRET, etc). Compared to a managed secrets system (Vault, Infisical) it adds zero operational burden — the encrypted file is the source of truth, the age private key is the trust root. Trade-offs: no UI, no read-audit, no automatic rotation.
- User Service
Manages users, sessions (Postgres-backed), and per-user trading limits. OAuth2 + PKCE. Internal only — never reached from the browser directly.
RBAC & desks
Roles, trading styles, desk segregation.
- Desk-head
Read-only oversight role with cross-desk visibility. Sees every desk's positions, blotter and P&L but cannot submit orders.
- High-touch
Manual, voice/keyboard-driven trading where a salesperson or trader works each order. Visible Order Ticket and Basket Order panels.
- Low-touch
Algo-driven trading where a trader monitors strategies running on the OMS rather than placing orders by hand.
- RBAC— Role-Based Access Control
Roles (trader, desk-head, risk-manager, admin, compliance, sales, external-client, viewer) gate which API endpoints and UI panels are accessible.
- Risk-manager
Second-line market-risk role. Sees firm-wide positions and risk panels (Greeks, vol surface, yield curve, DV01) but cannot trade.
- Trading style
Single primary specialisation that determines which panels a trader can open. Eight values: high_touch, low_touch, fi_voice, fx_electronic, commodities_voice, derivatives_high_touch, derivatives_low_touch, oversight.
Observability
Tracing, metrics and logs.
- Alert routing
The end-to-end path an alert travels from origin (Prometheus rule or Redux action) through the gateway or Grafana AlertManager to the Discord channel. See platform/observability/alerts for the full flow and operator runbook.
- Burst-open
k6 scenario simulating market-open conditions: 0 → 200 VUs over 30s, hold 5min, ramp down. Used to expose queue-depth and connection-pool ceilings.
- Discord webhook
URL credential that lets a service POST messages into a Discord channel. VETA uses one webhook to route CRITICAL and WARNING alerts from both the gateway (user-level events) and Grafana (platform alerts) into a single on-call channel. Injected via DISCORD_WEBHOOK_URL; never committed.
- DORA— DevOps Research and Assessment
Annual research correlating four metrics (deploy frequency, lead time, change failure rate, recovery time) with team performance. Used as the industry yardstick for software-delivery health.
- Error budget
The downtime an SLO mathematically permits. At 99.9% over 30 days = 43 minutes. When exhausted, feature work pauses and reliability work takes priority.
- Grafana Alloy
Telemetry collector. Receives OTLP from services, scrapes targets, ships to Loki/Prometheus/Tempo.
- k6
Grafana's open-source load-testing tool. JavaScript-defined scenarios with virtual users; emits metrics over Prometheus remote-write.
VETA's k6 scripts live in /k6 and define five scenarios used as one-shots in CI baselines and as continuous load via scripts/load.sh. The continuous loader runs k6 inside the loadgen-soak and loadgen-matrix containers with K6_NO_THRESHOLDS=true so threshold breaches don't terminate the loop.
- LGTM stack
Loki + Grafana + Tempo + Mimir/Prometheus. Grafana's bundle for logs, dashboards, traces and metrics. Run on the production server for the demo — a real-bank production should use a managed vendor.
- Loki
Log-aggregation database from Grafana. Indexes labels rather than full-text — fast and cheap, designed to be paired with Grafana.
- Matrix loop
VETA's continuous-load runner that cycles baseline-limit → mixed-strategy → burst-open → risk-stress forever, sleeping LOADGEN_MATRIX_SLEEP between scenarios. Complements the steady-state soak.
- MTBF— Mean Time Between Failures
Average duration between incidents. Tracked but not targeted — it rewards hiding problems and punishes better detection. The team metric is 'did we hit our SLO'.
- MTTD— Mean Time To Detect
Elapsed time from an incident starting to a useful alert firing. Bounded by monitoring quality — synthetic probes drive MTTD toward the probe cadence; without them MTTD is 'until a user complains'.
- MTTR— Mean Time To Recovery
Elapsed time from a page-able alert firing to the system being verifiably healthy again. VETA targets MTTR < 30 minutes on SEV1.
- OpenTelemetry
Vendor-neutral standard for metrics, traces and logs. Deno 2.x ships built-in auto-instrumentation enabled with OTEL_DENO=true.
- Risk-stress
k6 scenario hammering the risk engine specifically — 100 VUs constant for 2min, mostly orders that approach per-user limits to maximise risk-check work.
- RPO— Recovery Point Objective
Maximum data loss tolerated, measured in time. VETA targets RPO < 5 minutes, achieved via Postgres streaming replication.
- RTO— Recovery Time Objective
Maximum time to recover from disaster. VETA targets RTO < 30 minutes — automated Postgres failover plus a tested disaster runbook.
- SLA— Service Level Agreement
The contractual promise (usually involving money) if an SLO is missed. Always looser than the SLO so there's a buffer between 'we noticed' and 'we owe a refund'.
- SLI— Service Level Indicator
A specific user-facing metric (e.g. 'percentage of /orders requests returning 2xx within 500ms'). The number you measure to evaluate an SLO.
- SLO— Service Level Objective
The target you commit to for an SLI over a time window. VETA's headline SLO is 99.9% availability over 30 days; full table in the SRE terminology reference.
- Soak (test)
Sustained constant-VU load over a long window. VETA's soak.js holds 50 VUs by default in the continuous loader; meant to surface slow leaks (memory, descriptors, queue depth) that don't appear under brief peaks.
- Synthetic monitor
Automated probe that performs a complete user journey on a schedule (sign in, open WS, submit a test order, cancel it). Source of truth for 'is the platform up'. Runs outside the cluster to see what real users see.
- Tempo
Distributed-tracing backend from Grafana. Stores traces by ID; a separate metrics-generator processor produces span-metrics and a service graph.
- traceparent
W3C-standard HTTP header (and Kafka header) that carries the active trace ID and parent span ID, letting receivers stitch a distributed trace.
- VU— Virtual user (k6)
k6's concurrency unit — a simulated user running one iteration of the script at a time. Soak holds VUs constant; ramp/burst scenarios scale up and down across stages.