External market data identifiers

The Reuters Instrument Code, now called the Refinitiv Identification Code but still universally referred to as RIC, is a ticker-like code that Reuters — and, through successive acquisitions, Refinitiv and now LSEG (London Stock Exchange Group) — has used since the 1980s to identify tradeable instruments and indices across its market data terminals and feeds. It is the oldest of the schemes covered in this document and carries that history in its design: rather than a single systematic grammar, RIC is a loose family of per-asset-class conventions that grew organically as new instrument types were added to Reuters' systems over decades — an equity RIC appends an exchange suffix (AAPL.OQ), an index RIC is prefixed with a dot (.SPX), an FX spot RIC appends an equals sign (EUR=), and credit/rates RICs often carry a broker-specific suffix (ICAP, GFI) reflecting which inter-dealer broker's screen the quote was sourced from. There is no independent standards body governing RIC — it is entirely owned and controlled by LSEG as a proprietary asset of its data business, and there is no open, publicly published specification: the authoritative definition of RIC syntax exists only inside the licensed Refinitiv Data Platform / Eikon / Workspace customer documentation, accessible to paying subscribers. Using RIC as an identifier therefore means depending on a data vendor's proprietary naming scheme rather than an open standard, and, mechanically, on characters (= and .) that many downstream systems — including hierarchical pub/sub subject naming — cannot carry unescaped. No dedicated open-source C++ library for parsing or generating RIC syntax was found; LSEG's own Real-Time SDK (formerly RFA / the Enterprise Message API, written in C++) consumes RIC-tagged real-time feeds, but it is itself a proprietary, licence-gated SDK aimed at feed consumption, not a general-purpose open parser. See LSEG Data & Analytics for the vendor's own (login-gated) documentation portal, and the Reuters Instrument Code Wikipedia article for a general-audience, non-authoritative summary.

The Bloomberg ticker is Bloomberg L.P.'s own instrument-identification scheme, used throughout the Bloomberg Terminal and its programmatic interfaces since the Terminal's introduction in the early 1980s. Unlike RIC, every Bloomberg ticker follows one consistent two-part shape: a free-form ticker string followed by a space and a "yellow key" — a short, explicit asset-class tag such as Equity, Curncy, Index, Comdty, or Corp (e.g. AAPL US Equity, EURUSD BGN Curncy). That yellow key gives Bloomberg tickers a more systematic feel than RIC — a reader can always tell the asset class from the last token — but the internal structure of the ticker portion itself still varies by asset class: an equity ticker carries an exchange code (US, LN) as part of the ticker, while an FX or rates ticker does not, so there remains no single universal grammar that a program could apply uniformly across asset classes. Bloomberg ticker syntax is entirely proprietary to Bloomberg L.P.; there is no open standards body and no publicly published formal specification — the authoritative reference exists only inside the licensed Bloomberg Terminal and Bloomberg API (BLPAPI) customer documentation. No dedicated open-source C++ library for parsing or generating Bloomberg ticker syntax was found. Bloomberg's official BLPAPI C++ SDK lets a client query data by passing a ticker string, but it is itself a proprietary, licence-gated query API rather than an open parsing library, and it does not parse or validate ticker syntax on the client side — the string is passed through as an opaque key to Bloomberg's own backend for resolution. Bloomberg does maintain a large open-source C++ presence (its BDE, Basic Development Environment, libraries), but these are general-purpose foundational libraries and are unrelated to ticker parsing. See Bloomberg Professional Services for the vendor's own (login-gated) documentation, and the Bloomberg Terminal Wikipedia article for a general-audience, non-authoritative summary.

The ORE canonical key is the identifier scheme native to the Open Source Risk Engine (ORE), an open-source pricing and risk analytics library. Unlike RIC and Bloomberg, it was not designed as a market-data vendor's product identifier — it was designed purely as ORE's own internal input format for the marketdata.csv files that feed every ORE pricing run, and it is defined and owned entirely by the ORE open-source project, currently maintained by Acadia (formerly Quaternion Risk Management / AcadiaSoft). Because it exists to serve one program's input format rather than to label instruments for human traders across a whole industry, it is the most systematic of the three short-string schemes: every key follows the same top-level slash-delimited shape, TYPE/SUBTYPE/dim1/.../dimN, regardless of asset class — though, unlike a flatter scheme, the number and meaning of the dimensions after TYPE/SUBTYPE is fixed per type rather than universal (see ORE quote key structure below for the detail this simplification glosses over). There is no external standards body governing it either, but — in sharp contrast to RIC and Bloomberg — its specification is entirely open: the format is defined by ORE's own open-source code and by the example marketdata.csv files shipped with every ORE release, all of it freely readable without a licence of any kind. A C++ library for parsing and generating this format already exists and ships as part of ORE itself: the OREData library's CSVLoader reads marketdata.csv files into ore::data::MarketDatum objects keyed on this exact structure, and the same classes serialise back out to CSV — there is no separate parsing library to seek out, because parsing and generation are first-class, built-in parts of ORE. See Open Source Risk Engine — project home and OpenSourceRisk/Engine on GitHub (the Examples/ directory contains the marketdata.csv files this key format is drawn from; OREData/ored/marketdata/ contains the CSVLoader=/=MarketDatum parsing code).

MDDL is an XML-based market data description language originally developed by the Financial Information Services Division (FISD) of the Software & Information Industry Association (SIIA), first published in the early 2000s; see Market Data Definition Language (MDDL) for its full version history and current status. Structurally it differs from the short-string schemes covered here: RIC, Bloomberg, and the ORE canonical key are each a short single string that is the identifier, whereas MDDL is a full XML instrument record, and instrument identity is carried by an instrumentIdentifier container element (a code plus a codeType controlled vocabulary) nested inside that record — MDDL does not mint a competing short-string notation of its own, it wraps whichever identifier the source system already uses (ISIN, RIC, a vendor ticker, …). Its specification is open and committee-governed rather than proprietary to a single vendor, in contrast to RIC and Bloomberg, but unlike ORE's canonical key it was never adopted as any single pricing engine's native input format. The last full specification release is MDDL 3.0-beta (2007-03-01); FISD never published a later version, instead contributing MDDL's vocabulary toward ISO 20022 and the FIX Protocol. Files retrieved from the (now defunct) mddl.org are archived at external/mddl/.

FIX is a wire message protocol and field/message dictionary maintained by the FIX Trading Community (formerly FIX Protocol Ltd.), first published in 1992; see Financial Information eXchange (FIX) Protocol for its full version history and content model. Unlike MDDL, FIX was never wound down — it remains the dominant open standard for pre-trade, trade, and post-trade messaging and, since 2019, is continuously extended as "FIX Latest" rather than released in numbered versions. It is the only one of the six schemes here with a dedicated market data message family: MarketDataRequest, MarketDataSnapshotFullRefresh, MarketDataIncrementalRefresh, and MarketDataRequestReject (plus MarketDataStatisticsRequest/Report and MarketDataReport added in FIX 5.0 SP2) — RIC, Bloomberg, the ORE key, and MDDL each define an identifier or record shape, but none defines the wire messages that move a live tick from producer to consumer the way FIX does. Instrument identity is carried by the Instrument component's Symbol=/=SecurityID fields tagged with a SecurityIDSource (tag 22) enum — the same wrapping approach MDDL's codeType takes, and the enum explicitly includes RIC_CODE and BLOOMBERG_SYMBOL as named member schemes, alongside CUSIP, SEDOL, ISIN_NUMBER, and others. Its specification is open, committee-governed, and free of vendor licensing, much like MDDL and ORE's canonical key, in contrast to RIC and Bloomberg. Files retrieved from the QuickFIX open-source engine project (which redistributes the FIX Trading Community's own data dictionaries) are archived at external/fix/.

OpenGamma Strata is an open-source Java library for OTC derivatives pricing and risk analytics, originally developed by OpenGamma Ltd and now maintained by the open-source community. Its identifier abstraction, com.opengamma.strata.data.MarketDataId<T>, differs fundamentally in kind from the other five schemes covered here — it is a Java generic interface, not a string format or wire protocol. The Javadoc describes it as "an identifier for a unique item of market data… Implementations can identify any piece of market data. This includes observable values, such as the quoted market value of a security, and derived values, such as a volatility surface or a discounting curve." The interface's only contract is uniqueness and a declared value type T (the type of the value the identifier resolves to — e.g. double for a spot rate, or a curve object for a full discount curve). All field structure is pushed down into each concrete implementing class; there is no single canonical field list at the interface level by design. Strata's rationale is extensibility across an open-ended set of data kinds a third-party library cannot anticipate in advance, in contrast to schemes that commit to a shared field shape across instrument types.

Unlike every other scheme in this document, there is no canonical short string a consumer would use as a compact map key or pub/sub subject; the identifier is the Java object, not a serialisation of it. Strata does not mint a competing short-string notation and does not define a wire-message protocol. Like ORE's canonical key and unlike RIC, Bloomberg, MDDL, and FIX, Strata's MarketDataId is also silent on physical fields at the interface level — an implementing class is free to carry a source or convention, but nothing at the base contract requires or names one.

The library is open source (Apache 2.0) and its source and Javadoc are freely readable without a licence of any kind. See OpenGamma/Strata on GitHub; the identifier interface lives in the com.opengamma.strata.data package, and concrete implementations such as QuoteId, IborIndexId, and CurveId illustrate the per-class field shape the interface deliberately omits at the base level.

Comparative analysis

• RIC: major pairs use base currency code + =; crosses use the 6-char pair + =; outright forwards append tenor + F. Shortcoming: the encoding is inconsistent even within FX itself — a major pair and a cross are different string lengths, and the forward suffix (F) changes the meaning of the += character rather than adding a clean, separate field, so a parser cannot reliably split "currency pair" from "instrument type" without an asset-class-specific rule table.
• Bloomberg ticker: the ticker portion mirrors RIC's currency-pair string, but the yellow key (Curncy) and BGN fixing tag are always explicit, separate tokens. Shortcoming: still a flat, space-delimited string with no distinction between "the pair" and "the tenor" for a forward (EURUSD1M packs both into one token, same weakness as RIC's F suffix, just with different characters).
• ORE quote key: FX spot is a scalar series with no point_id segment; the FX forward row's 1M is a genuine point_id — forward points form a term structure per currency pair, and ORE's schema has a dedicated dimension for that, unlike RIC or Bloomberg. Shortcoming: this uniformity is bought by having a separate top-level TYPE (FX vs FXFWD) for spot vs. forward rather than one type with a tenor dimension that is merely absent for spot — spot and forward are not, in ORE's own model, the same series with an optional extra field; they are two different series types that happen to share a currency pair.
• MDDL: no short-string row — a foreignExchangeDomain record identifies the pair via instrumentIdentifier and carries the rate itself as bid=/=ask=/=mid container elements (each an mdDecimal plus inheritable currency=/=crossrate properties), rather than a single scalar the way ORE's FX/RATE/EUR/USD is. Shortcoming: three separate elements (bid=/=ask=/=mid) for what RIC, Bloomberg, and ORE each treat as a single quoted rate means a consumer must know which of the three fields a given feed actually populates — the schema does not mandate all three be present together.
• FIX: no short-string row either — a MarketDataSnapshotFullRefresh identifies the pair via the Instrument component's Symbol (free text, e.g. EUR/USD) and carries bid/offer as MDEntryType 0=/=1 entries in MDFullGrp, the same shape used for every other asset class in this document. Shortcoming: FIX has no FX-specific SecurityIDSource value — a currency pair is just a Symbol string with no controlled-vocabulary backing the way RIC's += suffix or MDDL's foreignExchangeDomain at least signal "this is FX" structurally.

<mddl version="3.0-beta" xmlns="http://www.mddl.org/mddl/3.0-beta">
  <header>
    <dateTime>2026-07-26</dateTime>
    <source>EBS</source>
  </header>

  <snap>
    <dateTime>2026-07-26T12:00:00</dateTime>
    <snapType>tick</snapType>

    <foreignExchangeDomain>
      <instrumentIdentifier>
        <name>EUR/USD spot</name>
      </instrumentIdentifier>

      <currency>USD</currency>
      <crossrate>EUR</crossrate>

      <bid>
        <mdDecimal>1.0842</mdDecimal>
      </bid>
      <ask>
        <mdDecimal>1.0844</mdDecimal>
      </ask>
    </foreignExchangeDomain>
  </snap>
</mddl>

(Constructed for illustration from the retrieved schema's foreignExchangeDomain element structure — see external/mddl/mddl-3.0-beta-full.xsd — not copied from a real feed; no worked FX example was included in the retrieved release's Examples/ set.)

8=FIX.4.4|9=140|35=W|49=SENDER|56=TARGET|34=1|52=20260726-12:00:00.000|
262=MDREQ002|
55=EUR/USD|
268=2|
269=0|270=1.0842|271=1000000|273=12:00:00.000|
269=1|270=1.0844|271=1000000|273=12:00:00.000|
10=044|

(Field-per-line for readability; | stands in for the real SOH delimiter. Constructed by hand from the retrieved FIX 4.4 dictionary — see external/fix/FIX44.xml — not copied from a live feed; BodyLength (tag 9) and CheckSum (tag 10) are illustrative placeholder values, not computed from the actual message bytes.)

Comparative analysis

• RIC: a broker-composite suffix (ICAP, GFI) or a Reuters-composite tag (RR) is appended to a base code per instrument — USDSB5Y=ICAP for a swap par rate, US10YT=RR for a government bond yield. Shortcoming: the suffix vocabulary is not itself systematic — ICAP=/ =GFI name a specific inter-dealer broker while RR names a composite calculation method, so the same trailing-code slot means two different kinds of thing depending on asset class, and a raw overnight fixing (SOFR) has no RIC row of its own at all in this table.
• Bloomberg ticker: the yellow key stays a stable, explicit tag (Curncy, Index) across every rates instrument in this table. Shortcoming: unlike RIC, there is no visible broker/composite provenance in the ticker itself — USSA5 Curncy does not say whether the quote is a specific broker's screen or a Bloomberg-generic composite, information RIC at least surfaces via its suffix.
• ORE quote key: keys are per the ORE market data catalogue's documented IR_SWAP/RATE/CCY/spot_lag/float_index_tenor/swap_tenor and DISCOUNT/RATE/CCY/curve_id/tenor shapes — richer than the simplified series_type/metric/qualifier[/point_id] shown later in this document (see ORE quote key structure). Shortcoming: ORE has no standalone type for a raw overnight fixing or a sovereign bond's own yield-to-maturity — SOFR enters only as an index-tenor dimension inside IR_SWAP/RATE or via OI_FUTURE/PRICE, and government yields are represented, if at all, via the generic ZERO/RATE curve-construction type rather than a bond-specific yield quote; treating a ZERO/RATE point as equivalent to a Treasury or Bund's quoted yield is an approximation, not an identity, since ZERO/RATE is a curve input, not a specific bond's yield-to-maturity. No RIC/Bloomberg row above lines up one-to-one with an ORE key and vice versa — the RIC/Bloomberg rows quote par rates or fixings for specific indices/tenors, while the ORE rows are term-structure series (a tenor dimension carries the point on the curve).
• MDDL: for the USD 5Y IRS par rate row, a generic instrumentDomain record's interestRateContainer sub-container (rate, period, compounding, accrual, …) can carry a swap's fixed-rate terms, with instrumentIdentifier naming the instrument and instrumentType an open, source-defined value (no fixed enumeration of instrument types ships in the schema itself, unlike MDEntryType in FIX or ORE's TYPE/SUBTYPE). Shortcoming: because instrumentType is open-vocabulary, two MDDL producers could each publish a 5Y USD swap under different instrumentType strings with no schema-level way to detect they mean the same thing — a structural gap none of RIC, Bloomberg, or ORE's fixed vocabularies have.
• FIX: has no standard, widely-documented Market Data convention for publishing an OTC swap's par rate as a tick — swap rates are typically negotiated/executed via FIX's order and trade-capture messages (multi-leg Instrument=/=InstrmtLegGrp structures) rather than streamed through MarketDataSnapshotFullRefresh. Shortcoming: this is the same broker-composite, not-retail-ticker gap RIC and Bloomberg both have for this row — none of the schemes here has a clean, publicly documented tick-level convention for an IRS par rate, only ORE's IR_SWAP/RATE key (a pricing-engine input, not a market feed convention) comes close.

Comparative analysis

• RIC and Bloomberg ticker: neither vendor has a documented public convention for swaption volatility — it is inherently broker-composite, over-the-counter data (sourced from inter-dealer brokers such as ICAP or Tullett Prebon) rather than data with a standardised single-vendor ticker convention. Shortcoming: this is a genuine gap in public documentation for both vendors, not an omission from this table — a consumer needing swaption vol by RIC or Bloomberg ticker must go through a broker's own proprietary screen naming, which neither vendor publishes.
• ORE quote key: the key follows the catalogue's documented SWAPTION/RATE_LNVOL/CCY/expiry/swap_tenor/strike shape — a genuine advantage here, since it is the only one of the short-string schemes with an openly documented structure for this instrument at all. Shortcoming: the four-dimension surface coordinate (expiry, tenor, strike) is carried entirely inside the point_id segment, so — unlike the FX or rates rows — a consumer must already know this type's specific dimension count to parse the key; the same top-level shape gives no hint that a swaption key has three trailing dimensions where an FX key has none.
• MDDL and FIX: neither has any documented representation for a swaption volatility surface point in the retrieved specification material — no dedicated instrument type, message, or property was found for expiry/tenor/strike-keyed implied vol in either the 3.0-beta schema or the FIX 4.4/5.0 SP2 dictionaries. Shortcoming: this is a genuine gap for all four of the non-ORE schemes here, not just RIC and Bloomberg — swaption vol is broker-composite, over-the-counter data that none of RIC, Bloomberg, MDDL, or FIX has a standardised public convention for; ORE's SWAPTION/RATE_LNVOL key remains the only openly documented structure for this instrument among all six schemes compared in this document.

Comparative analysis

• RIC: a single suffix convention covers both single names and indices — an exchange suffix (.OQ = NASDAQ, .L = London) for tradeable names, a leading dot for indices (.SPX, .FTSE), and c1 for a continuous front-month future. Shortcoming: the meaning of the leading . character is overloaded — it marks "this is an index" for .SPX but is also, confusingly, part of the exchange-suffix punctuation for .OQ=/.L=, so a parser cannot treat a leading dot as a reliable index marker without also checking position.
• Bloomberg ticker: the yellow key distinguishes equities from indices explicitly (Equity vs. Index) rather than relying on punctuation position. Shortcoming: no verified public ticker convention was found for a listed equity future (ES1 Index is plausible but unconfirmed here), so Bloomberg's coverage gap for this instrument class cannot be documented with the same confidence as its spot conventions.
• ORE quote key: keys follow the catalogue's documented EQUITY/PRICE/ENTITY/CCY shape (SP5 is the catalogue's own documented entity code for the S&P 500; the others are constructed the same way, since ENTITY is a free-form ticker/index-ID field, not a fixed enumeration) — a single, uniform shape for both single names and indices, unlike RIC's punctuation split. Shortcoming: ORE's equity asset class covers spot, dividend yield, and forward price only (EQUITY/PRICE, EQUITY_DIVIDEND/RATE, EQUITY_FWD/PRICE) — no listed-equity-future quote type is documented, so "S&P 500 front-month future" (an exchange-traded futures contract, distinct from the OTC equity forward ORE does support) has no ORE representation at all, a gap neither RIC nor Bloomberg has for this instrument.
• MDDL: has no equivalent row above, because it does not identify an equity with a short string at all — it wraps a full instrumentDomain record around whichever codes the source already publishes. The example below is adapted, for like-for-like comparison with this table's Apple row, from the retrieved real worked example mddl-equity-example1.xml (Lafarge SA, an EOD equity snap — see that file for the authentic, unmodified vendor example); the shape is unchanged, only the instrument-specific values (name, codes, currency, market) are substituted. It shows an instrumentIdentifier carrying two codes at once (an exchange/ticker code and an ISIN, each tagged with its own scheme URI) plus a nested marketIdentifier (an ISO 10383 MIC) and instrumentData/instrumentType. Shortcoming: this is far richer than any RIC, Bloomberg, or ORE row above, but it is also not a compact key — there is no single short string a consumer could use as a map/dictionary key or a pub/sub subject the way AAPL.OQ, AAPL US Equity, or EQUITY/PRICE/AAPL/USD can be used directly.

<mddl version="3.0-beta" xmlns="http://www.mddl.org/mddl/3.0-beta">
  <header>
    <dateTime>2026-07-26</dateTime>
    <source>NASDAQ</source>
  </header>

  <snap>
    <dateTime>2026-07-26</dateTime>
    <snapType>EOD</snapType>

    <instrumentDomain>
      <instrumentIdentifier>
        <name>Apple Inc</name>
        <code scheme="http://www.mddl.org/ext/scheme/symbol?SRC=TICKER">
          <mdString>AAPL</mdString>
        </code>
        <code scheme="http://www.mddl.org/ext/scheme/symbol?SRC=ISIN">
          <mdString>US0378331005</mdString>
        </code>

        <instrumentData>
          <instrumentType>equityCommon</instrumentType>
        </instrumentData>

        <marketIdentifier>
          <code scheme="http://mddl.org/ext/scheme/iso10383.xml">
            <mdString>XNAS</mdString>
          </code>
        </marketIdentifier>
      </instrumentIdentifier>

      <currency>USD</currency>

      <last>
        <mdDecimal>229.10</mdDecimal>
      </last>
    </instrumentDomain>
  </snap>
</mddl>

(Trimmed for brevity — namespace/schema-location attributes and comments elided. Adapted from the real retrieved example at external/mddl/mddl-equity-example1.xml; instrumentType and element shapes are unchanged from that authentic file. Instrument values are substituted for comparability with this table's Apple row, and one code scheme URI is swapped from the original's local-exchange-code scheme (.../symbol?SRC=ISO6166-style) to a ticker-symbol scheme (.../symbol?SRC=TICKER), since AAPL is a US ticker rather than a local exchange code the way the original file's LG was — the ISIN code's scheme URI is unchanged.)

• FIX: like MDDL, has no short-string row above — instrument identity travels inside a MarketDataSnapshotFullRefresh (35=W) message's Instrument component, tagged with a SecurityIDSource (tag 22) naming which external scheme the accompanying code belongs to; the same message's MDFullGrp repeating group carries the actual price points (bid/offer/trade/…). Unlike MDDL's rich but message-less XML record, FIX pairs a comparably rich instrument description with a dedicated wire-level delivery mechanism — the MarketDataRequest=/ =MarketDataSnapshotFullRefresh=/=MarketDataIncrementalRefresh message family — that none of the other five schemes define. Shortcoming: FIX messages are typically consumed and generated through a FIX engine rather than read as a standalone document the way an MDDL or ORE marketdata.csv file can be; correctly parsing tag=value framing (session header, checksum, repeating groups) requires that engine or an equivalent decoder, whereas RIC, Bloomberg, ORE, and MDDL are all readable with generic string/XML tooling alone.

8=FIX.4.4|9=185|35=W|49=SENDER|56=TARGET|34=1|52=20260726-10:15:00.000|
262=MDREQ001|
55=AAPL|48=US0378331005|22=4|
268=2|
269=0|270=229.10|271=500|273=10:14:59.500|
269=1|270=229.15|271=300|273=10:14:59.500|
10=087|

(Field-per-line for readability; a real FIX message is a single SOH-delimited (\x01) string, shown here with | standing in for SOH and line breaks added only for display. 55=Symbol=AAPL, 48=SecurityID=US0378331005 (a CUSIP), 22=SecurityIDSource=4 ISIN_NUMBER; 268=NoMDEntries=2, each entry an MDEntryType=/=MDEntryPx=/ =MDEntrySize=/=MDEntryTime tuple — 269=0 is BID, 269=1 is OFFER, per the retrieved FIX 4.4 dictionary's MDEntryType enum. Constructed by hand from the dictionary for illustration, not copied from a live feed — see external/fix/FIX44.xml for the authoritative field/message definitions this example is built from; BodyLength (tag 9) and CheckSum (tag 10) are illustrative placeholder values, not computed from the actual message bytes.)

Comparative analysis

• RIC: a single broker-suffix convention (GFI) covers both an index and a single name, appended after a tenor-and-currency-qualified base code. Shortcoming: as with rates, the broker suffix leaks a specific inter-dealer broker's identity into the instrument key rather than naming the credit instrument in vendor-neutral terms.
• Bloomberg ticker: has a clean, explicit ticker for the CDS index (ITRX EUR 5Y Corp) but no verified public ticker convention for the single-name CDS. Shortcoming: single-name CDS coverage cannot be documented with the same confidence as the index — a real gap in Bloomberg's publicly visible conventions for this instrument class.
• ORE quote key: keys follow the catalogue's documented CDS/CREDIT_SPREAD/entity/seniority/CCY/tenor shape (entity is a free-form reference-entity name, not a fixed enumeration; SR = senior) — the same shape covers both the index and the single name, unlike Bloomberg's asymmetric coverage. Shortcoming: this shape only covers the credit spread itself; ORE separately models CDS index tranches (as opposed to the index spread) via the dedicated CDS_INDEX/BASE_CORRELATION / INDEX_CDS_TRANCHE/BASE_CORRELATION types, not shown here, so the same "credit" asset class is split across quote types that a consumer must know to look for separately.
• MDDL: has no dedicated credit-derivative domain (there is no creditDomain among the schema's eight top-level domains) — a CDS index or single-name CDS would have to be modelled as a generic instrumentDomain record with an open, source-defined instrumentType value, the same open-vocabulary gap noted for interest-rate swaps above. Shortcoming: no worked example for a CDS instrument was found in the retrieved 3.0-beta release, so unlike the equity and FX cases, this is not just "no compact key" but "no documented convention at all" for this instrument class.
• FIX: later FIX versions add trade-capture support for credit default swaps (e.g. a CDSInstrument product qualifier), but no standard, widely-documented Market Data tick convention was found in the retrieved FIX 4.4/5.0 SP2 dictionaries for a CDS index or single-name spread — as with IRS par rates above, CDS spreads are broker-composite OTC data, not something MarketDataSnapshotFullRefresh is commonly used to stream. Shortcoming: same gap as RIC/Bloomberg's single-name row — none of RIC, Bloomberg, MDDL, or FIX documents a public tick-level convention for credit spreads with the confidence ORE's CDS/CREDIT_SPREAD key has as a pricing-engine input.

Comparative analysis

• RIC: treats gold spot as FX-like (XAU=, the same trailing-= convention as an FX pair) and continuous futures with a c1 suffix. Shortcoming: reusing the FX += convention for gold spot means a parser cannot distinguish "this is a currency pair" from "this is a metal" without a lookup table of known metal codes — the syntax itself carries no asset-class signal.
• Bloomberg ticker: uses Comdty as an explicit, unambiguous asset-class tag for both futures and spot (CL1 Comdty, XAU BGN Curncy being the one exception, since gold is quoted through the FX desk). Shortcoming: that same gold exception shows the yellow key is not fully reliable as an asset-class signal either — gold spot carries Curncy, not Comdty, so a consumer still needs asset-specific knowledge to interpret it correctly.
• ORE quote key: keys follow the catalogue's documented COMMODITY/PRICE/entity/CCY (spot) and COMMODITY_FWD/PRICE/entity/CCY/tenor (forward strip) shapes — GOLD is the catalogue's own documented entity code, and unlike RIC, gold gets its own COMMODITY type rather than borrowing FX's. Shortcoming: ORE has no separate "front-month future" type distinct from a point on the COMMODITY_FWD/PRICE tenor strip, so the WTI/Brent rows use 1M as a representative near-dated tenor rather than a dedicated front-month construct — the same spot/forward type-split seen in the FX section recurs here.
• MDDL: a commodityDomain record's applicable properties are just description, instrumentIdentifier, and last — deliberately narrow, since the schema's own annotation says this domain is "often used with a derivative like future or option" (i.e. commodity futures are expected to be modelled via instrumentDomain referencing the commodity, not entirely inside commodityDomain itself). Shortcoming: unlike RIC's FX-borrowing or Bloomberg's Curncy exception, MDDL at least gives gold its own domain distinct from FX — but that domain's three-property scope is noticeably thinner than foreignExchangeDomain's bid=/=ask=/=mid or instrumentDomain's much larger property set.
• FIX: commodities and commodity futures use the same generic Instrument=/=MarketDataSnapshotFullRefresh shape as every other asset class — SecurityType (a separate, general field) rather than a commodity-specific message family distinguishes a commodity future from an equity or FX instrument. Shortcoming: this genericity is a double-edged sword — it means FIX never needs a new message for a new asset class, but, unlike MDDL's dedicated (if narrow) commodityDomain, nothing in the message shape itself signals "this is gold" beyond the Symbol string and SecurityType value.

<mddl version="3.0-beta" xmlns="http://www.mddl.org/mddl/3.0-beta">
  <header>
    <dateTime>2026-07-26</dateTime>
    <source>LBMA</source>
  </header>

  <snap>
    <dateTime>2026-07-26</dateTime>
    <snapType>EOD</snapType>

    <commodityDomain>
      <instrumentIdentifier>
        <name>Gold spot</name>
      </instrumentIdentifier>

      <currency>USD</currency>

      <last>
        <mdDecimal>2412.50</mdDecimal>
      </last>
    </commodityDomain>
  </snap>
</mddl>

(Constructed for illustration from the retrieved schema's commodityDomain element structure — see external/mddl/mddl-3.0-beta-full.xsd — not copied from a real feed; no worked commodity example was included in the retrieved release's Examples/ set.)

8=FIX.4.4|9=132|35=W|49=SENDER|56=TARGET|34=1|52=20260726-17:00:00.000|
262=MDREQ003|
55=XAUUSD|
268=1|
269=2|270=2412.50|271=100|273=17:00:00.000|
10=118|

(Field-per-line for readability; | stands in for the real SOH delimiter. 269=2 is TRADE per the retrieved FIX 4.4 dictionary's MDEntryType enum. Constructed by hand — see external/fix/FIX44.xml — not copied from a live feed; BodyLength (tag 9) and CheckSum (tag 10) are illustrative placeholder values, not computed from the actual message bytes.)

Every ORE quote key shares the same top-level shape, TYPE/SUBTYPE/dim1/dim2/.../dimN, but the number and meaning of the dimensions after TYPE/SUBTYPE is fixed per type, not universal — an IR_SWAP/RATE key has five dimensions (currency, spot lag, float index tenor, swap tenor), an EQUITY/PRICE key has two (entity, currency), and a CAPFLOOR/RATE_LNVOL key has six. The table below shows this shape at a simplified, four-field level of abstraction (series/metric/qualifier/ point), which is a useful mental model but understates the real dimension count for most types — see the ORE market data catalogue for the authoritative, per-type dimension inventory (49 distinct types) that every row in this document's comparison tables above draws from.