Security definition (instrument reference data)
A security definition is the machine-readable record an exchange publishes for each tradable instrument: its identifier and symbol, product and expiry, tick size and contract multiplier, listing exchange, matching algorithm and, for a spread, its legs. Where a contract specification describes a product for people, the security definition describes one instrument for software.
Senzoukria · Glossary · Updated September 2026
What it contains
- Identity: a numeric instrument id and the exchange symbol, such as ESZ6.
- Product and expiry: the root, the contract month, the last trading date.
- Price grid: minimum tick and the value of a point or tick.
- Market structure: listing exchange, trading hours group, matching algorithm, price banding and limit parameters.
- For spreads and combinations: the legs and their ratios, which is how software tells a spread from an outright.
Definition versus specification
A contract specification is the product document: what ES represents, its tick, its listed months and settlement. A security definition is published per instrument and changes with each listing: ESZ6 and ESH7 are two definitions of one product, and so is every calendar spread between them. Exchange feeds such as CME's MDP 3.0 publish definitions on a dedicated channel so that software can build its instrument table before reading prices.
Worked example: the value of one tick
Tick value is tick size multiplied by the multiplier. ES: 0.25 × 50 = $12.50. The 2-year Treasury note ZT: 0.00390625 (1/256 of a point) × 2,000 = $7.8125. Japanese yen futures 6J: 0.0000005 × 12,500,000 = $6.25. A definition read with the wrong multiplier gives every P&L figure the wrong scale, even though prices display correctly.
In Senzoukria
The application does not read exchange definitions; it uses its own catalogue of 53 CME, CBOT, NYMEX and COMEX roots, each with tick size, multiplier, tick value, delivery months and expiry rule. A root absent from the catalogue gets generic defaults, a 0.25 tick and a multiplier of 1, so its simulated P&L and point value are wrong until the root is added. The tick hint shown in the symbol picker is informational: the renderer infers the real tick size from incoming trades. The Databento importer shows the other side of the problem: a parent symbol such as MNQ.FUT is not imported, because without the definitions a spread in its mapping cannot be told apart from a contract.
Common mistakes
- Assuming prices that look right mean the multiplier is right.
- Treating a spread instrument as an outright because its symbol shares the root.
- Hard-coding a tick size that the exchange later changes for a product.
Related
- Contract specifications
- Tick size
- Tick value
- CME Group exchanges
- Matching engine
- Contract specifications and expiry rules
In the same section
- Self-match prevention
- Scripting
- Sequence number
- Scaling plan
- Session range
- Scaling out
- Session review
- Sample size
This page in other languages
Frequently asked questions
- Where can I see an instrument's definition?
- Exchanges publish them in their market data feeds and reference data files, and data vendors expose them through their APIs. Contract specification pages summarise the same information per product for readers.
- Why does my P&L look wrong on an unusual contract?
- Often because the software does not know the contract's multiplier or tick value and falls back to a default. Senzoukria applies a multiplier of 1 to roots outside its catalogue, which leaves prices correct but P&L on the wrong scale.