Security level status - Use Case and Gap Analysis

As a global IT project manager working at an Asian exchange, I would like to ask around in this forum about security-level status and Market Maker order respectively and figure out some general Use cases and any possible Gaps with FIX standard.

  1. Security(Instrument) level Status:
    In normal, all the securities within a market segment will have the same trading schedule and our system sends ‘Trading Session Status’ per each segment through both Trading Gateway(GW) and Market Data Distribution GW. However, for unplanned events or Trading Session changes (refer to some examples below) at individual security level, we privately define new messages and is published to the members and data vendors via both GW of Trading and Market Data Distribution system.
    [Examples]
    (1) Volatility Interruption: one of price stability mechanisms targeting a single stock, turns continuous
    trading method into call auction as a cooling-off measure in case of temporary dramatic changes in
    stock prices.
    (2) Random end(RE): enforces orders of the call auction to be executed at a random time point, not at
    the predetermined time of execution. It was introduced in order to protect investors from price
    distortion caused by fraud orders.
    (3) Initial price of newly listed stock: As for newly listed a stock, its price has not been established in the
    exchange markets in the first place, so that appropriate reference price should be re-evaluated.
    The reference price of the newly listed stock is determined by opening call auction on the new listing
    date, and this price is published as the initial price of this newly listed stock.

My questions are:
1) Should I have to privately define a new message for this business feature? or Is there any possibility to
use standard message instead?
2) If we found any possible standard message but it is required for user defined fields to fulfill our business
requirements, then is it still compliant with FIX semantic or misuse of the standard message?

  1. Market Maker Quote
    As a market maker system, our market also introduces Liquidity Provider(LP), a designated member who is obligated to provide liquidity by reducing gaps the bid/offer spread as set forth in its contract with our exchange. Since market has no clear distinction between quotes suggested by market makers and orders submitted by general members, the Liquidity Provider as a market maker also use the general orders when they fulfill the duty on liquidity providing.
    As far as I know, the difference between the LP’s orders and the FIX standard Quotation is the processing for the replacement/modification request: An existing order is replaced by a replace order and the client ID of the replacing order(the price and time priority will be renewed based on the associated principles). However, in the FIX standard, the price or quantity of the existing quotation can be modified but the original quote ID will be unchanged(thus, no need to have its own quote ID for the replacing quotation) until the full execution or cancellation.
    Of course, you would ask to use the general order(Single New order, replace order) instead of using FIX quotation for the LP order, but we chose the FIX quotation because we couldn’t find any other alternative in order to support two-side quotation for the LP(market maker). Given the reason and just to reflect our current method for order replacement as mentioned above, we added ‘QuoteMsgID(1166)’, which is not a required tag in FIX standard spec, by defining it as the ID of replacing quotation and also defined the meaning of ‘QuoteID(117)’ as the ID of the existing quotation, which is different from its original meaning in the spec.

My questions are:
1) Is our customization or implementation of LP’s order using FIX quotation as above misusing the FIX standard or not compliant to its intended semantic?
2) If yes, what is alternative way to reduce the gaps or your recommendation to resolve this non-compliant issue?

Thank you so much for your advise in advance!

Let me address your first area. Modeling of markets and trading (sub-)sessions in conjunction with session and instrument states is highly complex and often driven by quite specific business requirements. The 3 examples you give above illustrate that. FIX offers a very rich set of functionality to cover almost any use case out there, i.e. there should be no need for user-defined fields, let alone user-defined messages. There are two principle concepts I can give you to steer you in the right direction.

First concept is about static information aka reference data related to market behaviour and trading sessions. This is covered by the set of FIX market definition messages, primarily MarketDefinition(MsgType=BU). It contains multiple components on the root level defining the applicable rules. These can be made specific to a trading session by means of TradingSessionList(MsgType=BJ) and its component TradingSessionRules. They can further be made specific to an individual instrument by means of SecurityDefinition(MsgType=d) and its component MarketSegmentGrp. You can also view these as a hierachy, i.e. start defining things on a market or market segment level and only use the same component on the trading session level or instrument level if you need to override the market or market segment level.

Second concept is about dynamic information. This only applies to the trading session level by means of TradingSessionStatus(MsgType=h) and the instrument level by means of SecurityStatus(MsgType=f) and SecurityMassStatus(MsgType=CO). This is where you can deviate from the static information, e.g. trading schedules and convey state changes as well as events occurring throughout the trading period. The TradingSessionStatus can be limited to multiple instruments by means of its Instrument component, i.e. basically supporting any level between individual instruments and all instruments of a market or market segment. Furthermore, you can use the SecurityMassStatus message to define a set of instruments on the basis of filter criteria and exclude specific instruments from that list by means of the SecMassStatGrp.

The design is the complex part as FIX most likely offers much more than you actually need. If you do identify a gap you should first try the forum to establish whether it is really a gap. If it is then it is FIX-compliant to add such fields to standard FIX messages as long as you do not replace key fields such as message- or entity-level identifiers, status/quantity fields (even if they are not defined as mandatory in FIXimate). The FIX semantic hinges on the presence of key fields but there is no pre-defined list of these per message as it also depends a little bit on the given use case…

As a FIX member, you can address gaps through working groups and committees that can submit so-call Gap Analysis documents to the FIX Global Technical Committee to extend the FIX standard.