Market Data Requirement

A requirement is only useful if two independently-written requirements can be compared and recognised as the same need — otherwise nothing could deduplicate work, cache a resolution, or reason about which requirements a trade population collectively generates. The attributes that compose a market data requirement's identity are:

Two requirements are the same requirement precisely when every one of these attributes is equal. Whether the point and as-of attributes belong to the requirement's identity itself, or are better modelled as parameters passed alongside a coarser, curve-level requirement, is a design decision this document does not settle in the abstract — it is precisely the distinction drawn below between the static requirement set (which does not yet know the as-of date, or often even the specific point) and the dynamic requirement set (which does).

The static requirement set for a trade type is the set of market data requirements that every instance of that type needs, purely as a consequence of what kind of trade it is — before any specific trade, any specific currency pair, or any specific valuation date has been named. "Every FX Forward requires two interest rate curves, one for each currency in its pair" is a static requirement: it is true of the FX Forward product type as a category, derivable from the product's definition alone, and it does not change from one FX Forward to the next or from one day to the next.

Formally, if \(\mathcal{T}\) is the space of possible trade types, the static requirement set is a function

\[\mathrm{static}: \mathcal{T} \to \mathcal{P}(\mathrm{Requirements})\]

mapping each trade type to a set of requirements (using \(\mathcal{P}(\cdot)\) for "power set of") — deliberately a function of the type alone, with no dependence on any particular trade instance, currency, or date. Re-evaluating \(\mathrm{static}(\text{FxForward})\) tomorrow yields the same set as today, because nothing about the FX Forward product definition itself changed overnight.

The static set says an FX Forward needs "two interest rate curves, one for each currency in its pair" — but it cannot say which two currencies, because it is a function of the type alone, and every FX Forward shares the same type regardless of whether it is EUR/USD or JPY/GBP. The instance requirement set closes that gap: it binds the static set's structural slots (currency, currency pair, index name, credit name, curve role) to one specific trade's actual attributes. "This trade is a EUR/USD forward, so it needs the EUR and USD discount curves, specifically" is an instance-level statement.

Formally, given a specific trade \(t\) of type \(\tau(t) \in \mathcal{T}\),

\[\mathrm{instance}(t) \subseteq \mathrm{static}(\tau(t))\]

Two properties make this level worth naming separately rather than folding it into either its neighbours. First, it needs no valuation date and no analytics to compute: which curves a EUR/USD forward touches is fixed the moment the trade is booked, by simply reading its currency pair and index fields — no cashflow generation, no schedule, no model. Second, it is stable over the trade's life in a way the level below it is not: the set of curves a trade instance touches does not change from one valuation date to the next, only which points within those curves it touches does. A EUR/USD forward booked today will still need "the EUR and USD discount curves" a year from now, even though the specific tenor points it needs will have shifted as it rolls towards maturity.

The dynamic requirement set refines the instance set for a specific valuation date. Where the instance set can only say "this forward needs the EUR and USD discount curves," the dynamic set can say "this forward, maturing in 87 days, needs those two curves' 3-month tenor points specifically" — a statement that depends on a fact the instance set has no access to: what today's date is.

Unlike the instance/type binding above, this step is not a lookup — for anything beyond the simplest linear products it requires running the same cashflow-generation and, where applicable, model machinery the valuation itself will eventually use (exercise dates for an option, reset and payment schedules for a swap, barrier monitoring dates for an exotic), just far enough to know which points on a curve or surface those cashflows will read from. This is why the dynamic set, not the instance set, is where most of the genuine complexity in requirement derivation lives.

Formally, given a specific trade \(t\) of type \(\tau(t) \in \mathcal{T}\) and a valuation date \(d\),

\[\mathrm{dynamic}(t, d) \subseteq \mathrm{instance}(t) \subseteq \mathrm{static}(\tau(t))\]

— the dynamic requirement set is a refinement of the instance set: it narrows any curve-level requirement down to the specific points that trade instance's cashflows actually touch on date \(d\). In practice a dynamic set is usually a proper subset — an instance requirement for "the whole EUR discount curve" narrows to "the EUR discount curve's 3M and 6M points" for one particular short-dated forward — though nothing in the definition forbids equality when a trade genuinely needs every point a term structure offers, such as a full-curve sensitivity calculation.

Separating static, instance, and dynamic requirement derivation is not merely a taxonomic nicety — it is what makes large-scale requirement generation computationally tractable at all, because the three levels have sharply different costs. A trading book with ten thousand FX Forwards does not need its static requirement set computed ten thousand times; \(\mathrm{static}(\text{FxForward})\) is computed once for the type, and every instance of that type shares it. The instance refinement — binding "the two currencies' curves" to "the EUR and USD curves, specifically" — is cheap: it runs once per trade, but is pure attribute lookup, no analytics involved, and stays valid across every valuation date until the trade itself changes. The dynamic refinement — narrowing "the EUR discount curve" down to "these specific points, for this specific maturity, as of this date" — is where the real cost sits: it runs once per trade per valuation date, and for anything beyond a linear product it means re-running enough of the pricing model's own cashflow logic to know which points it will read. Knowing a book needs EUR and USD curves at all is nearly free; knowing exactly which points on those curves a thousand American swaptions and barrier options need today is not.

The distinction earns its own name specifically because behavioural would have been the natural word to pair against static — "static configuration vs. runtime behaviour" is a familiar contrast in software engineering generally — but that pairing was deliberately rejected. "Behavioural" suggests the requirement set changes as a side effect of how the system runs (caching, retries, feature flags); what actually varies between the static and dynamic requirement sets is not runtime behaviour but the arguments available at each stage — a trade's type is known before the trade itself is booked, and a trade's specific maturities and the day's date are known only once. "Static" and "dynamic" name that temporal and informational distinction directly, without implying anything about system behaviour that is not actually there.