Market Data Universe
Table of Contents
Summary
The market data universe \(U\) is the set of every market data item that exists in the system at a given moment — every curve, every spot rate, every volatility surface point that could, in principle, be looked up by a market data identifier. No single valuation ever needs the whole of \(U\); what a valuation actually uses is a much smaller market data set \(\mathrm{MDS}(T)\) — a subset of \(U\), derived from it by resolving a population of trades' requirements, expanding the result into its full dependency closure, and intersecting with \(U\) itself to account for the possibility that not everything requested actually exists. This document defines \(U\) precisely and argues for the set-notation vocabulary used throughout this cluster. The step-by-step derivation of \(\mathrm{MDS}(T)\) from \(U\), with a worked example, is in Market Data Requirements and Resolution.
Terminological conventions
Analogy: the market data universe as the routable Internet
If a market data requirement is a domain name and a market data identifier is an IP address, the market data universe is the entire routable Internet — every machine reachable at every valid IP address, all at once. No single web request ever touches more than a vanishingly small fragment of that whole; a browser loading one page resolves a handful of domain names into a handful of addresses and opens exactly that many connections. The rest of the Internet's several billion addressable machines are simply irrelevant to that one page load, without the Internet itself needing to shrink or reconfigure to make them so. The market data universe plays exactly this role for a valuation: it is the totality of everything addressable, of which any one valuation touches only a small, requirement-derived slice.
The analogy illustrates why set language, rather than environment language, is the right vocabulary for \(U\). An "environment" suggests something a valuation is configured to run inside of — a fixed, walled container assembled ahead of time to hold exactly what that valuation needs and nothing more. That is a reasonable description of what \(\mathrm{MDS}(T)\) looks like once it has been carved out, but it is misleading for \(U\) itself, which is not walled or valuation-specific at all — it is simply everything that exists, the way the whole Internet exists regardless of which pages any particular browser happens to be loading right now.
The same objection applies to \(\mathrm{MDS}(T)\), the valuation-scoped subset. Terms like "environment" connote something ambient and configured once per run — closer to a deployment's environment variables than to a value that varies per trade, per valuation date, and per pricing engine. Engine-specific terms like "ORE's today's market" were also considered and rejected: they tie the concept to one engine's vocabulary and do not generalise to Bloomberg- or Reuters-sourced data, nor to the static/instance/dynamic structure the cluster relies on. "Set" was chosen because \(\mathrm{MDS}(T)\) genuinely is a set — closed under union, intersection, and closure, with subset and membership tests that matter operationally (does this valuation's requirement set fall inside \(U\)?). The mathematical vocabulary is not a metaphor layered on top but a precise description of how these objects behave. The payoff is that most of the relationships in this cluster collapse from paragraphs of prose into a single line of notation, checkable the way an algebraic identity is checkable, rather than merely plausible the way a prose description is.
Formal definition
\(U\) is the set of every market data identifier addressable in the system at a given moment, together with the data item each identifier addresses. Membership in \(U\) is a factual, not a logical, question — an identifier is a member of \(U\) if and only if the system actually has data for it right now, regardless of whether anything has asked for it. This is the property that makes \(U\) the right place to model the "no available market data" failure mode as ordinary set membership: a resolution can, entirely correctly, produce an identifier that does not happen to be a member of \(U\) — the requested curve genuinely does not exist, was never loaded, or has not yet been published — and that failure is nothing more exotic than testing \(x \in U\) and finding it false.
See also
- Market Data Requirements and Resolution — the hub.
- Market Data Requirement — the logical starting point of the pipeline.
- Market Data Identifier — what a member of \(U\) is addressed by.
- Market Data Configuration — \(\rho\), resolution.
- Market Data Dependency Resolution — \(\mathrm{closure}\).
- Market Data Filtering — further narrowing of a valuation-scoped market data set.