9100-product-def-core

#	Message Name	Description
9115	CCodeDefinitionV3	Commodity code (product code) definitions for all futures, and the ccode -> SpiderRock ticker map. Sourced from listing exchange product definitions. Also covers exchange and user-defined spreads, including spreads used as option underliers; SpiderRock uses a compact form of the exchange spread product ID as the ccode where no human-readable exchange ticker exists. A family head begins with '@'; no product key or uplink does. Two links. Field 103 ticker is the LINE the product derives from: a single-name product names its equity line (the EquityDefinitionV3 9106 row with the ISIN), an index product its index line (IndexDefinitionV3 9109), a dividend product its parent's dividend line; a commodity, rate, FX or futures-on-futures product, and any product its region cannot resolve, names itself. Never a @ head. Nothing hangs on an obligor. Field 250 familyHead is the FAMILY: one venue's products on one underlier, @[underlier]-[venue]-FUT, a head a loader names after its outright (@ES), or a declared family (the common US families: ES and MES under @ES, VXM and its TAS under @VIXMIN), whose Primary is declared with it. Every product is its own complex; a head answers through the family's Primary. DOMAIN TERMS ARE ATTACHED RECORDS on the same ccode pkey, not fields here: RepoTermsDefinitionV3 9245, TbaTermsDefinitionV3 9248, SwapTermsDefinitionV3 9251, ReceiptBasketDefinitionV3 9254. READ symbolType TO CLASSIFY THE CCODE (CCode | RepoProduct | TbaContract | SwapProduct | CommodityProduct), never the presence of a terms record.
9148	CorpActionDefinitionV3	THE FUNDAMENTAL EVENT, once: a 3:2 split is ONE row here and thousands of KeyTransform edges. Machine-coded AND legal/textual. Carries the lifecycle - announced, REVISED, effective, cancelled - under a STABLE actionKey: revisions change terms, never identity (the occurrence-identity lesson)
9169	DeliveryBasketDefinitionV3	One row per delivery basket: what one adjusted option contract settles into when a corporate action leaves it delivering MORE THAN ONE LINE. The basket is keyed so the contract has one thing to point at, price against and settle into. THE KEY IS '_' + THE ADJUSTED ROOT ('_AAPL1'), on the root's source. A further adjustment mints a new root and so a new basket, which is what makes a basket immutable: its contents are what one adjustment fixed, and a later adjustment is a new row rather than an edit. RootDefinitionV3 names the basket in ticker and carries no composition of its own. A BASKET EXISTS ONLY WHERE A ROOT DELIVERS MORE THAN ONE LINE. Every other shape is the root alone: one line is ticker plus underliersPerCn; one line plus cash adds cashOnExercise; cash alone keeps ticker on the original line with multihedge AllCash and the cash in cashOnExercise (the underlier level then reads zero). Cash-settled index and equity options get no basket and no special treatment. THE SPINE ROW IS REQUIRED. TickerKeyDefinitionV3 (9100) carries symbolType DeliveryBasket for this key and is what makes it resolvable; a basket without it names contents nobody can reach, and a spine without a basket names a key with no contents. This is not an index. IndexDefinitionV3 (9109) is for lines whose level is computed from constituents; a basket is a settlement instruction, and its terms are fixed by an adjustment rather than reweighted.
9106	EquityDefinitionV3	THE EQUITY LINE - one row per equity-family ticker: a share class, ETF, ADR, depositary receipt or fund, the satellite that TickerKeyDefinition's symbolType selects. The facts of the line itself and of the chains that settle into it. A cash index's line is IndexDefinitionV3's (9109). ONE LINE PER CURRENCY, and each line heads its own complex: each quotes, prices and holds positions in its own currency, and the lines of one ISIN all carry that ISIN. A European line (tickerSrc SCE) is keyed [base]^[ccy] (SAP^EUR; NOKIA^EUR and NOKIA^SEK for a share that trades in two currencies), where [ccy] is the money currency, so a line quoted in pence is ^GBP; its bare base (SAP) is no key. A line from any other source keeps its plain ticker (NMS AAPL). Every option root and futures product whose exercise delivers these shares settles into the line in its own currency. A venue's book is a VenueListingDefinitionV3 (9139) row on the line in its currency naming its quoteKey, never a second line and never a row here. The line's parent in the tree is its obligor (obligorKey); nothing sits between them. ABSENCE IS THE ASSERTION. A key that is not an equity line has no row. A futures product head has none: every futures product is its own complex and reads CCodeDefinitionV3 (9115). A venue's market-data key (TickerKeyDefinitionV3 symbolType VenueListing) has none.
9166	FamilyPrimaryElectionV3	One row per futures family, keyed by the family head: CCodeDefinitionV3 (9115) familyHead, @[line]-[venue]-FUT for a venue's products on a line, or the @X head a product names. primary is the product MAR counts the family in (a sibling's contract counts as its point value over the Primary's) and the product a FUT head answers through; CCodeDefinitionV3 (9115) role Primary follows it. THREE RUNGS, STRICT ORDER (governs). HardCode: declared in code (the common US families, a micro under its E-mini; a FUT head named after a product, ES under @ES; the Europe loader's table); no edit of this row moves it, a release does. Election: this row decides, whoever wrote it, until written again. Rule: no row exists, so the loader elects the standard outright (kind Outright, else Physical, else any; never a TAS contract) with the largest point value, then contract size, then symbol, writes this row and publishes the family's 9115 rows with roles. A Rule row follows the rule on later loads; an Election or HardCode row stays as written. rulePrimary is what the rule elects today: a difference is research, not a change. STATUS. Elected: primary governs. Dead: the elected product is not in the load; the family has no Primary and every order on it is refused at MAR arrival (SpdrRejectReason MarNoPrimary) until a new election is written. None (the SRSE default on a hand-written row) governs and is stamped by the next pass. Pending and Superseded are reserved: such a row does not govern and the check reports it. A written row relinks its family within the session; counters accumulated for the day keep the old Primary's contracts until the trade-date roll.
9121	FutExpiryDefinitionV3	One row per futures contract - the expiry-rung counterpart of OptExpiryDefinitionV3. A PRODUCT CARRIES A RULE, A CONTRACT CARRIES DATES AND TERMS. The listing rule (listingCycle, undExpiryRule) is on CCodeDefinitionV3; the resolved dates for one contract are here. Margin is not here - SpanRiskParameters (4370) keeps it.
9109	IndexDefinitionV3	THE INDEX KEY IS THE LINE: every root and ccode that settles on this index points at this key, its live level rides on IndexQuote (2675) under it, and the facts a share line carries on EquityDefinitionV3 (9106) an index line carries here. A key with a row here and no 9106 row is an index line. {Component} is what the index is composed OF; indexType says which kind of composed-of line this is. A DERIVED line names what it derives from in baseIndex and how in derivation, and has no components. Another calculator's level arrives under a QUOTE PATH: a market-data key whose TickerKeyDefinitionV3 (9100) row is symbolType IndexQuote and up-links here, with no row here and no complex. The official SOQ and close are IndexSettlementMark (3185) rows. A DELIVERY BASKET is DeliveryBasketDefinitionV3 (9169), not a row here. indexType DeliveryBasket is retired in place: no producer writes it and the bridge check names a row that still carries it. A DIVIDEND LINE has derivation DividendPoints: its level is the gross cash dividends of baseIndex since the annual reset, in index points. An index's is the provider's published index under its own symbol; a share's is minted by SR, keyed '~' + the share's symbol. Every dividend future names it as ticker, never the share or price index - a dividend contract is not a share delta. indexType Dividend is retired in place.
9151	KeyTransformV3	THE EDGE: one row per (transit, childKey, parentKey) pair - a scatter is 1 parent x N children, a gather N x 1, a triangular merger M x N with per-pair terms. THE TABLE IS A DIFF: the identity edge (self-parent, 1:1, no cash) is NEVER stored - the only reason key-level lineage is affordable at options-chain scale. Lineage is a DAG by construction: edges point back exactly one period
9142	MarketHoursV3	The expected market schedule for one product group on one trade date - the session times a client needs to know when orders are accepted and when each session opens and closes. Typically holds the current week, the previous week and the next week. ScheduleDefinitionV3 (9057) holds the calendar, rotation window and venue for the same (tickerSrc, tickerClass, scheduleGroup) key. This record holds only what varies BY DATE. RESOLUTION: look up the product's exact scheduleGroup; if there is no row, fall back to scheduleGroup '*'. FOUR SOURCES, ONE LADDER. Every source publishes its own row and the reader takes the best one present - Manual beats Loader beats Bridge beats HardCode - skipping any row marked deleted.
9118	OptExpiryDefinitionV3	This table maps option root/expiration combinations to their deliverable future. Mappings are sourced fromm listing exchange product definitions. PRECEDENCE FOR uPrcDriverKey RUNS ROOT OVER EXPIRY: RootDefinitionV3's value overrides this record's. A zero or empty field here is NOT POPULATED, never an override to zero. EXPIRY RUNG - NO SPINE ROW. pkey is ekey:ExpiryKey, so by the pkey-shape test this is a satellite at a deeper rung than TickerKeyDefinition and needs no symbolType value. The rung ladder in one record: root (TickerKey) -> this (ExpiryKey) -> Option (OptionKey). The record attaches to rootObject; there is no business object at the expiry rung yet.
9172	OptionContractSizeOverride	The deliverable of ONE option series where it differs from its root/expiry. Euronext adjusts a chain for a corporate action by re-sizing individual series in place (e.g. FRO on Oslo: 102 shares per contract beside 100-share series under the same root), where Eurex mints a new root (CFRv1). The root and expiry rungs cannot describe a chain whose series deliver different amounts, so the answer for such a series lives here, at the option rung. PRECEDENCE RUNS OPTION OVER EXPIRY OVER ROOT: when this row is loaded with underliersPerCn > 0, Option.UnderliersPerCn answers from it; otherwise the option falls back to OptionExpiry.UnderliersPerCn (which itself falls back to the root). A zero here is NOT POPULATED, never an override to zero. No row means the series delivers what its root says. OPTION RUNG - NO SPINE ROW. pkey is okey:OptionKey, one rung below OptExpiryDefinitionV3 (ekey) and RootDefinitionV3 (root).
9130	ProductExchMappingV3	EXCHANGE-ASSIGNED IDENTIFIERS - one row per (instrument, venue). The ephemeral, hot half of what was one ProductMapping table. | THIS RECORD (exchange) | ProductMapping (registry/vendor) lifecycle | EPHEMERAL - intraday to weekly | PERMANENT identity residency | HOT, resident in every routing | reference data | and ingest process | writers | PER-EXCHANGE FEED HANDLERS | vendor loaders (EDI, GLEIF, OpenFIGI) volume | 10^4 - 10^5, churning daily | one ISIN per instrument The writer axis is the one that forces it rather than merely favours it - the same reason SpreadExchID exists as rows instead of a repeater. A table written by per-venue handlers and by vendor loaders together has two purge horizons and two hot/cold profiles in one resident set. THERE IS NO extKeyType HERE, AND THAT IS THE POINT. For an exchange-assigned identifier the TYPE AND THE AUTHORITY ARE THE SAME FACT - 'CBOE's id for this thing' - so the venue IS the type. mic is key material and no separate type field is needed. That collapses the old venue-scoped-versus-global question rather than answering it.
9112	RootDefinitionV3	One row per option root: its underlier, its delivery and exercise terms, and its pricing conventions. Sourced from the listing exchange for future options and from OCC for US equity options, and updated as SpiderRock receives changes. Field 100 ticker is the MASTER UNDERLYING - the containing complex - which is not the same key as the root itself.
9100	TickerKeyDefinitionV3	One row per (TickerKey, tickerClass) - the join spine at the ticker rung. Holds only what is true of EVERY TickerKey; kind-specific facts live on satellites (RootDefinitionV3, CCodeDefinitionV3, BondIssueDefinitionV3, ObligorDefinitionV3 ...). TickerDefinition (4375) and TickerDefinitionExt (4380) are computed PROJECTIONS of this record. REGISTRY IDENTIFIERS ARE NOT HERE. isin, cusip, figi, lei and the Bloomberg codes ride ProductMappingV3 (9127); the 4375 projection reads them back out of it. WHICH KEYS GET A ROW is decided by pkey shape: TickerKey-pkeyed -> a row here, one per role the key plays ExpiryKey-pkeyed -> a deeper rung (Future, OptionExpiry) - no row OptionKey-pkeyed -> a leaf (Option, Bond, Pool, Tranche) - no row Futures ccodes and option roots are ticker-rung and DO get rows; the contracts and bonds beneath them do not.
9139	VenueListingDefinitionV3	A LISTING IS A CONTEXT, NOT AN INSTRUMENT. The fungible line - one ISIN - gets ONE SR ticker key, and each venue it trades on gets a listing row binding that key to (MIC, venue symbol, trading currency, venue calendar). THERE IS NEVER A KEY PER VENUE; that would fragment positions and risk across copies of one thing. The same ISIN quoted in two currencies is two listings, one key. Market data arrives per listing - MarketSourceDefinitionV3 per venue. The books of one reference market fold into a MARKET COMPOSITE, [line]^[market letter], a spine row under the line named here by compositeKey; the line key carries the primary market's composite. A currency composite, [line]^[ccy], sums the market composites in one currency. Roots price off a composite (RootDefinitionV3 9112 uPrcDriverKey). DISTINCT LINES ARE NOT LISTINGS OF EACH OTHER. A/B share classes, national lines and ADR/GDRs have their own ISINs, so they are separate keys joined by fungibility edges carrying conversion terms.
9160	VenueTradingRulesV3	THE VENUE'S TRADING RULES FOR ONE PRODUCT - one row per (product, venue). Block-trade (Eurex TES), price-improvement (Eurex CLIP) and partition parameters the venue publishes per product and the execution engine reads when it builds a cross. They are rules, not identifiers and not terms: a rule can change intraday by venue notice while the product's definition does not, so they live apart from CCodeDefinitionV3 (9115) and RootDefinitionV3 (9112). THE WRITER IS THE REFERENCE LOADER THAT LISTS THE PRODUCT (the Activ loader for Europe). It takes the partition from the venue's product table and the TES and CLIP parameters from the venue parameter loader's EurexTesProfile and EurexClipProfile rows. One row per product. Where the venue bands TES by expiry range, {TesBand} carries every band and tesBlockMinLotSize and tesNonDisclosureLimit carry the front band. 0 MEANS THE VENUE PUBLISHED NO SUCH RULE: tesBlockEligible = No with tesBlockMinLotSize 0 is "no TES on this product"; clipMaxQty 0 is "not CLIP-eligible". Readers fail safe to the on-book path.