Market Model Reference

Prodigy utilises pluggable Market Models to represent all primitives on a Market:

• Market
• Symbols
• Orders
• Trades
• Announcements

Outside of these basic primitives, each Market Model allows for custom operations and logic to define how the market functions.

Available Models

Out of the box, Prodigy provides the Standard model.

Creating Models.

Additional models are written in a .Net compatible language and made available to the Prodigy services to be loaded at runtime.

Models consist of three main components:

• Data Model - describes the primitives, their properties, and the events that affect them. Events are deterministic and, when played back in sequence, will always result in the same market state.
• Execution Engine - describes what operations exist and how they are applied to the Data Model.
• Translator - translates the representation of primitives in the Data Model to a simplified format for FIX messages and historical data warehousing.

Prodigy requires a minimum set of operations, such as market configuration, symbol management, news, and basic order manipulation (place/amend/cancel). The execution engine can define any number of additional operations, such as status management, bulk order manipulation, auction triggers.

Each component of the Market Model is specified independently when creating a Market. This allows for some advanced scenarios:

• Using the same Data Model with multiple Execution Engines, to customise how the market functions without requiring an entirely new representation. Eg: alternative auction logic.
• Using the same Data Model with a different Translator, to customise what information is exposed through FIX and historical data warehousing. Eg: dark markets or limiting the visible order book depth.

Configuration vs State

For Markets and Symbols, Prodigy makes a distinction between long-term configuration and short-term state.

Long-term configuration describes the core properties of a Market or Symbol. Eg:

• Market Timezone.
• Symbol CFI Code.

Short-term state describes properties that frequently change on a Market or Symbol Eg:

• Market or Symbol Trading Status.
• Reference Prices.

There are significant differences in how these different properties are handled.

• Long-term configuration is stored independently in the database for fast review, while short-term state generally requires full event replay.
• Changing long-term configuration captures documentation on the reason for the change, while short-term state does not.
• Long-term configuration changes generate different events to short-term state changes:
  • Long-term changes will trigger a SecurityList FIX message.
  • Short-term changes will trigger a MarketDataIncrementalRefresh FIX message.