Market Data Identifier

RIC and Bloomberg are the two most widely deployed vendor notations and the primary projection targets any market data system must be able to produce. Both are proprietary, with no open specification; both have grown organically per asset class, accumulating broker suffixes, yellow-key tags, and asset-class-specific conventions that cannot be recovered field-for-field from any logical description alone. Neither has a curve-family or curve-role concept — the logical distinctions that matter most to a pricing engine (discounting vs. projection, log-normal vs. normal vol) are absent from both. RIC and Bloomberg are identifiers within their own vendors' namespaces, not descriptions in a shared logical vocabulary.

ORE's canonical key is the only openly documented format among the six that covers the instrument types a derivatives pricing engine actually needs. Its slash-delimited structure — <series_type>/<metric>/<qualifier>[/<point_id>] — provides a uniform top-level shape across 49 documented types, making parsing and validation tractable. The survey also identifies an important terminological trap: ORE's internal CurveSpec class hierarchy is not a peer of the canonical key but a distinct artefact — a C++ representation of a resolved curve specification, and a target of vendor projection in its own right, not a logical identifier scheme. ORE's own comments sometimes call CurveSpec a "requirement," which the survey flags as a source of confusion worth naming explicitly.

MDDL and FIX take a different approach: rather than minting new identifiers, both wrap existing ones via a scheme-tag field (codeType in MDDL, SecurityIDSource in FIX tag 22). Neither is a pricing engine's native format. MDDL — last released in 2007, never finalised — contributed vocabulary to ISO 20022 and FIX before going dormant. FIX is the only scheme among the six with a dedicated market-data wire-message family (request, snapshot, incremental update), which is a structurally different role from the others; FIX explicitly names RIC and Bloomberg as member schemes, confirming that those two dominate the industry's wire identity practice.

OpenGamma Strata's MarketDataId<T> is the only scheme here that is a type abstraction rather than a string format or wire protocol. The Java generic interface carries no base-level field structure — all field definitions are pushed to implementing classes (QuoteId, IborIndexId, CurveId, and so on) — and it produces no canonical short string and carries no wire form.

Three findings from the survey directly shape the design described below.

All six schemes are silent on physical fields at their logical level. The ORE canonical key is purely logical; Strata's interface is purely logical by design; RIC and Bloomberg are vendor notations (physical in their own namespace) but do not provide a logical field group from which physical fields can be recovered. MDDL and FIX wrap external identifiers rather than defining their own field structure. The unanimity of this silence is not coincidence: it reflects the fact that physical fields are, by definition, vendor-specific — no scheme that aspires to vendor neutrality can define them, and no vendor scheme needs to expose them because it already is the vendor.

ORE and Strata independently converge on the same logical shape. Both arrive at an asset-class/type discriminator, a qualifying instance within it, and an optional further single-point coordinate — from different engineering traditions, with no shared vocabulary, as confirmed by direct inspection of both systems' source code. This convergence is the strongest available evidence that this three-part logical shape is irreducible: it reflects the concept's minimal necessary structure rather than either system's design history. The logical field group adopted below follows this shape directly.

RIC, Bloomberg, and ORE's CurveSpec hierarchy are the concrete instances of \(T_{\text{vendor}}\)'s targets. Each is an independently designed grammar that routinely collapses or omits information our identifier carries — tenor rounding, day-count assumptions, and broker-suffix conventions have no field-for-field correspondence to anything in a logical scheme — which is exactly why \(T_{\text{vendor}}\) must be one-directional and why recovering our identifier from a bare vendor key is a distinct ingestion problem, not an inverse of \(T_{\text{vendor}}\).

An identifier consists of exactly two field groups:

• Logical fields (\(L\)) — asset class, qualifier, curve role, and (for a single-point identifier on a term structure) the specific tenor or surface coordinate. These fields are shared with the requirement an identifier satisfies; a requirement is defined entirely within this group.
• Physical fields (\(P\)) — everything else a specific external vendor's own notation requires but a logical description never needs: which source supplied the value, calendar and day-count conventions, ticker-construction hints, and similar vendor-specific metadata.

An identifier is the pair \((L, P)\). A requirement is any element of \(L\) alone (or of \(L\) with the specific-point sub-field omitted, for curve-level requirements).

Two identifiers are the same identifier exactly when every field in both groups agrees:

\[(L_1, P_1) = (L_2, P_2) \iff L_1 = L_2 \;\text{and}\; P_1 = P_2\]

Equality of logical fields alone is not sufficient for two identifiers to be the same identifier — they might still differ in source or convention — but it is sufficient for them to share the same requirement, since requirement equality is defined purely over \(L\).

The projection from identifiers to requirements is

\[\pi : (L, P) \mapsto L\]

(discarding \(P\); for curve-level requirements, also discarding the specific-point sub-field from \(L\)). \(\pi\) is surjective and many-to-one: several identifiers, differing only in their physical fields, can project onto the same requirement. It requires no external information and admits no decision — it is purely a field-discarding map.

Resolution \(\rho\) runs in the opposite direction,

\[\rho : \mathrm{Requirement} \to \mathrm{Identifier}\]

but is not \(\pi^{-1}\). Given a requirement \(r\), there may be many identifiers \((L, P)\) with \(\pi(L, P) = r\); \(\rho\) must pick exactly one, using policy information (source preferences, convention choices) that \(r\) itself does not carry. Resolution is a genuine decision, not a computation on \(r\)'s fields.

For each external vendor, there is a one-directional transform

\[T_{\text{vendor}} : \mathrm{Identifier} \to \mathrm{VendorKey}\]

that renders an identifier into that vendor's own notation — a Bloomberg ticker, a Reuters RIC, an ORE CurveSpec — without inventing information the identifier does not carry. This is why physical fields must exist: the logical fields alone are insufficient to determine a vendor's notation, because vendor grammars depend on source, convention, and instrument-type classifications that have no counterpart in a logical description.

\(T_{\text{vendor}}\) is deliberately one-directional. Its inverse is not defined; recovering an identifier from a bare vendor key is an ingestion and reconciliation problem in its own right, addressed separately from this document.

The many-to-one character of \(\pi\) is a feature, not a defect: it is precisely what allows a valuation to state its needs in logical vocabulary ("the EUR discount curve's 3M point") without committing to a particular source or convention, and what allows the same requirement to be satisfied by different identifiers in different configurations — a prime source on one desk, a fallback source on another — without the requirement itself changing meaning. Several identifiers, all projecting onto the same requirement, are all valid answers; which one is chosen is the job of resolution, not of the requirement.

That \(\pi\) has no inverse is the structural reason resolution must exist as a separate concept. Given a requirement \(r\), the pre-image \(\pi^{-1}(r)\) is a set of identifiers (typically more than one), and \(\rho\) must select from it using information \(r\) does not carry. No amount of inspection of \(r\)'s fields alone can determine which element of \(\pi^{-1}(r)\) is wanted.

A vendor's own notation is an independently designed grammar, built for that vendor's own purposes. It routinely collapses or omits information our identifier carries: Bloomberg's yellow-key tag names an asset class but hides the curve role; RIC broker suffixes encode the source but in a format with no open specification and no field-for-field correspondence to our physical field group; ORE's CurveSpec hierarchy is structured for ORE's own C++ class hierarchy, not for our identifier's field layout. Two vendors can use two different notations for what is, logically, the same point. Recovering an identifier from a bare vendor key therefore requires vendor-specific parsing, semantic mapping, and in some cases a genuine choice (what does "EUSA5=" mean for a curve that our scheme calls DISCOUNT/RATE/EUR?). That problem is out of scope for this document.

A requirement is deliberately allowed to omit fields an identifier must carry. "The EUR discount curve" as a requirement says nothing about which source or convention satisfies it, or (at curve level) which specific point is needed, while the identifier it resolves to must by construction pick out exactly one concrete item in the market data universe. This asymmetry is not a defect to eliminate; it is the entire reason a requirement and an identifier are worth naming separately even though they are, structurally, one entity viewed at two levels of completeness. The narrowing from coarser requirement to exactly one precise identifier is resolution.