Trading Infrastructure & AI
Better trading decisions begin with better market-data infrastructure. Normalization, freshness and integrity set the limits of useful automation and AI assistance.
A pricing model can calculate precisely from an invalid market view. If the instrument mapping is wrong, a book update is missing or a reference is stale, a more elaborate model may make the resulting error harder to detect. The first question for trading infrastructure is whether the input is fit for the decision being made.
Normalize meaning before format
Converting several feeds into one message format is useful, but it does not make their prices comparable. A normalized instrument record needs the underlying asset, quote currency, venue, product type, unit convention and settlement terms. Spot units, derivative contracts and inverse-contract quantities cannot simply be added because their tickers resemble one another.
Prices also need context: bid, offer, last trade, index and mark price have different meanings. A last trade is not an offer available for the next order. For a size-aware pricing decision, retain enough depth to estimate the accessible quantity rather than substituting a ticker. Record tick size, quantity increments and fee assumptions separately from raw prices so that rounding and cost adjustments remain inspectable.
A useful data lineage connects the original source event to its normalized record, quality checks and downstream use. Preserve source identifiers and transformation versions. If a derived price changes unexpectedly, the investigation should be able to distinguish new market information from a mapping or processing change.
Freshness, liveness and integrity are different
Liveness asks whether the connection is functioning. Freshness asks how recent the relevant market observation is. Integrity asks whether the local state has been reconstructed correctly. A heartbeat can support the first without establishing the other two. Conversely, a quiet market can produce few changes without being stale.
Keep event time and local receipt time distinct, and use a monotonic local clock for elapsed processing time. Comparing clocks across machines requires synchronization and an allowance for uncertainty. Source-to-receipt age, processing delay and time since the last valid update are different measurements; combining them into one “latency” field hides the failure being diagnosed.
Protocol semantics matter as much as timestamps. Coinbase Exchange's WebSocket documentation, for example, defines its level2 update size as the absolute quantity at a price, not an increment. Its full-channel reconstruction uses a queued stream and snapshot sequence. Applying an absolute update as a delta corrupts the book even when every message arrives. Recovery and sequencing logic must follow the particular channel; there is no universal gap detector that fits all feeds.
For a concrete source-quality example, the pilot's API response assessment separates receipt latency from unverified book-event timestamp semantics. It describes that sample, not ongoing venue reliability.
Turn quality into an explicit decision
A quality gate should state the reason an input is accepted, degraded or unavailable. Useful checks include instrument validity, sequence continuity where provided, crossed or malformed books, implausible quantities, source age and divergence from comparable sources. A divergence flag should trigger diagnosis rather than automatically declare the outlying venue wrong: different instruments, funding conditions or genuine price discovery may explain it.
Pricing intelligence then works with eligible inputs and explicit constraints. It can compare accessible depth, fee-adjusted costs, inventory exposure and quote validity. A fallback must have its own purpose and limits. A slow reference might support a monitoring display while being unsuitable for an executable quote. Substituting it silently makes the interface look healthier precisely when the decision has become less reliable.
Monitoring should connect symptoms to action. “Feed degraded” needs an affected instrument set, an owner and a defined response: exclude the source, reduce permitted use, stop quoting or reconcile and rebuild according to policy. Recovery should demonstrate a valid state before restoring eligibility; reconnecting a socket is only one step.
Where AI assistance can be useful
A bounded analytical task is easier to evaluate than a promise of better trading decisions. Candidate uses include grouping related alerts, identifying unusual combinations of feed-quality signals and drafting incident summaries from approved records. Each output should retain its supporting event identifiers, time range and uncertainty so a reviewer can check it against the underlying evidence.
For a generative assistant, a fluent explanation is not evidence that the proposed cause is correct. Missing observations should remain missing, rather than being filled with a plausible narrative. The FSI paper on AI explainability discusses why explanations can themselves be unreliable and why governance, validation and monitoring remain necessary. This is the authors' analysis, not a claim that an explanation certifies a model's safety.
The control boundary matters: an analytical suggestion should not acquire authority to change limits, release funds or issue orders simply because it appears in an operational interface. Deterministic checks for permissions, valid states and exposure should apply independently of a model's confidence. Human review must have a named decision owner and a usable escalation path; adding an approval button alone does not establish effective oversight.
Evaluate the workflow, not the demonstration
Start with a task definition and a simpler baseline. For alert triage, measure missed material incidents and false alarms, not just aggregate classification accuracy. Include response time and reviewer workload. A model that suppresses many harmless alerts but hides one critical feed failure may perform well on the wrong metric.
For time-dependent market data, separate training and evaluation chronologically and prevent future information from entering features or labels used at decision time. Replay failures and recovery periods as well as ordinary sessions. Keep a record of data coverage, configuration and model versions so that results can be reproduced and compared after a change.
NIST AI RMF 1.0 provides a voluntary framework for defining context, assessing risks and documenting oversight and evaluation. In a trading workflow, a practical application is a limited rollout with monitored outcomes, an accountable operator and a tested rollback path. Performance outside the evaluation sample, changing market conditions and third-party model changes remain open risks.
Better infrastructure makes a decision explainable in operational terms: which observations were valid, which constraints applied and how an exception was handled. AI can assist that process only if it preserves the distinction between observed data, inferred patterns and authorized action.
Sources and scope
- Coinbase Exchange, WebSocket Channels — channel-specific update and reconstruction semantics; documentation checked October 18, 2026.
- NIST (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0) — particularly MAP 2.2, MAP 3.5 and the MEASURE function. A voluntary risk-management framework.
- Fernando Pérez-Cruz, Jermy Prenio, Fernando Restoy and Jeffery Yong (2025), Managing explanations: how regulators can address AI explainability, FSI Papers No 24 — authors' views on explanations and model governance.
Quality gates, monitoring choices and AI use cases here are editorial analysis. The incident and thresholds are hypothetical; no proprietary architecture, production data or claimed model results are presented.