The mapping inventory lists the vendor instruments each provider carries

Each pair is in market quoting order, as the feed quotes it, and maps to the item oresmd://fx/<base>?type=quote&instrument=fx_spot&quote=rate&ccy=<quote>. A collection quotes its own pairs, so a provider carries a row only for the pairs its own collection quotes, and the three providers map to one item where their collections quote the same market.

The Bloomberg collection quotes 26 pairs, each a ticker of the pair as six upper case letters and the yellow key Curncy, with the field PX_LAST:

The Demo collection quotes 11 of those pairs, each the pair with a slash and the field value:

The LSEG collection quotes 14 crosses, each the two currencies with the RIC's equals sign and the field BID:

• Bloomberg: the pair as six letters, a space and the yellow key Curncy, with the field PX_LAST. See Bloomberg data format.
• LSEG: the two currencies of the cross, an equals sign and the field BID. A pair against USD is written with the currency that is not USD alone. See LSEG data format.
• Demo: the pair with a slash, <base>/<quote>, with the field value. The provider is fictional and exists for exercises and demonstrations.

No id is minted. Each follows the vendor's own notation, so no row needs a deviation note.

Six currencies trade as deliverable spot and as a non-deliverable forward: INR, KRW, TWD, BRL, CLP and COP. For these the plain ticker may name the onshore market or the offshore one, and a pricing source may be needed. The rows are installed as written and marked to confirm. A person with access to the vendor's screen confirms or corrects them before a live adapter relies on them. The simulator publishes them as they stand.

A pillar is the quote that ends where the pillar ends, on the curve of one currency and one index. Its row names the currency, the index family, the instrument, the tenor the pillar starts at and the tenor it ends at, each in the words the curve template uses. Its item is the datum the pillar's own quote key names: the currency, the index tenor of the curve, and the two tenors of the pillar.

The rows come from the feeds, and no list of them is written here. For each IR curve config of each synthetic feeds collection, the seed emits one row for each Curve Template entry, in the notation of the provider the collection names. Today that is the 28 currencies of synthetic.feeds.bloomberg with their twelve-pillar spot-starting ladders, the 20 currencies of synthetic.feeds.uniform_demo with their three-pillar templates, and the five index curves of each of synthetic.feeds.ice and synthetic.feeds.tradeweb, which carry no id.

A pillar whose provider cannot write it has no row. The meeting-dated short end of the Bloomberg USD curve is spelled with meeting codes such as 1F, and no notation writes those, so the FOMC curve is quoted inside the system and not through an adapter.

• ICE and Tradeweb. The feeds quote index curves these providers carry in the real market, but their public documents give no id grammar for the asset classes they serve, so no notation is written for them and the seed has no row for their pillars or their pairs. The ore collection's two pairs have no notation either. See ICE data format and Tradeweb data format.
• Other fields. Only one field of each id is mapped: the last price for Bloomberg, the bid for LSEG. A bid and ask series, or a mid, is a further row for each field.

The notation agrees with the examples of External market data identifiers: EURUSD Curncy is a Bloomberg ticker with its yellow key, and EUR= is an FX spot RIC. The survey says the authoritative definitions of Bloomberg and LSEG notation are behind the vendors' logins, so the rows marked standard follow their documented examples and the common convention, and a person with a login confirms them with the rows marked to confirm.

The rows are installed by marketdata_vendor_instruments_populate.sql, which holds no list of either market: it reads each FX spot config and each IR curve config of every synthetic feeds collection, and joins what it reads to two generated lookup tables, one for the pairs and one for the pillars.

Those tables are written by tools/vendor_catalogue, which calls the provider's own notation for each id, calls the datum codec for a pair and make_pillar_quote_key with pillar_datum_uri for a pillar, and reads every id it wrote back to prove it names the same quote. The script's header holds the command that regenerates them, and the script stops, naming the pair or pillar, when a config quotes an instrument the tables have no id for. So the ids of this page and the ids the runtime writes cannot drift.

The ids of the vendor instruments come from their identity, so a second run writes the same rows. The mapping of each row holds from 2026-01-01.