Imported from previous forum
Question 1.
What status should securitytradingstatus convey to indicate it follows the trading session? (field 326)
Question 2.
According to Exchanges / ECN Working Group Recommended Best Practices Phase 1 : “Trading sessions can overlap within a single market segment”. How is this supposed to work? Can for example pre-trading and continuous trading overlap? Are orders then keyed on trading session?
(clarified the question a little)
Erik,
trading (sub)sessions and states are a complex area as the requirements are so broad and the delineation between them is blurred. A (sub)session name can easily be viewed as a state too. It might help if you see (sub)sessions as planned/scheduled elements (e.g. pre-open at 8:55am) and states as unforeseen elements (e.g. trading halt due to excessive price change). Therefore the best practices tried to cover as much ground as possible without being able to address all individual cases.
SecurityTradingStatus and TradSessStatus contain many different values today and are in my view not consistent. However it is very hard to change enum values without knowing who is using them and whose application one would break. Both fields should be used in a consistent manner, e.g. the session level overrides the security level or vice versa depending on the level of restriction. If the session is halted, the security pertaining to that session cannot be trading but the security can be halted if the session in general is trading. The security level should be much more granular than the session level and will reflect details of auctions for example (freeze, balancing,…).
To your second question: pre-trading and continuous trading cannot overlap due to the semantics tied to them. However, you could have session 1, session 2 and session 3 running in parallel with more or less overlap. The relevant issue is what kind of behaviour you need to attach to the elements/objects/groups in your environment. Differences in behaviour should be tied to the highest level possible, e.g. a (sub)session, a market segment or an entire market. Strictly sequential sub-sessions are much more common but we did not want to exclude the design of sessions with overlapping schedules, e.g. if they are tied to products than open and close at similar but not identical times and need to be traded very differently.
Hope this clarifies it a bit. It is easier if one has a specific requirement, it is hard to describe generically.
Regards,
Hanno.
Question 1. What status should securitytradingstatus convey to indicate
it follows the trading session? (field 326)Question 2. According to Exchanges / ECN Working Group Recommended
Best Practices Phase 1 : “Trading sessions can overlap within a
single market segment”. How is this supposed to work? Can for example
pre-trading and continuous trading overlap? Are orders then keyed on
trading session?(clarified the question a little)
Thank you very much for your reply Hanno!
Just as you described, I am planning on using the sub session ID as the different phases in the trading sessions, as recommended in the “Best practices”. But more exactly what is best practice for reporting the SecurityTradingStatus? To clarify a little more I will explain the problem I am facing (slightly simplified).
My TradingSession “DAY” consists of the phases: “CLOSED”, “PRE-TRADE”, “TRADE” and “POST-TRADE”. I convey information that we have entered pre-trade through TradingSessStatus. However during this phase a request asking for SecurityTradingStatus on a specific security appears. What should I reply? If I reply the security trading status is pre-trade, how should the recipient know this is only temporary (the status should for example not be updated if the security trading status is “halted” when going from pre-trade to continuous trading).
The solution I have been thinking of is to make a new SecurityTradeStatus value in the lines of “see trade session status” (perhaps this is something that should be added and given a default value if more approve) and only use strictly sequential trading sessions (hence my question about overlapping trading sessions) or use ‘17’ at all times unless it should override the trading session status. What do you think about this solution and does it follow best practice?
Thank you in advance!
Erik Scholander
Erik,
trading (sub)sessions and states are a complex area as the requirements
are so broad and the delineation between them is blurred. A (sub)session
name can easily be viewed as a state too. It might help if you see
(sub)sessions as planned/scheduled elements (e.g. pre-open at 8:55am)
and states as unforeseen elements (e.g. trading halt due to excessive
price change). Therefore the best practices tried to cover as much
ground as possible without being able to address all individual cases.SecurityTradingStatus and TradSessStatus contain many different values
today and are in my view not consistent. However it is very hard to
change enum values without knowing who is using them and whose
application one would break. Both fields should be used in a consistent
manner, e.g. the session level overrides the security level or vice
versa depending on the level of restriction. If the session is halted,
the security pertaining to that session cannot be trading but the
security can be halted if the session in general is trading. The
security level should be much more granular than the session level and
will reflect details of auctions for example (freeze, balancing,…).Hope this clarifies it a bit. It is easier if one has a specific
requirement, it is hard to describe generically.Regards, Hanno.
Yet another question on the topic of trading status and similar.
Heritage in market segments.
Is there any best practice or recommended uses for this? According to the Market Definition market segments can be arranged in a hierarchy (see field 1325). Is the intention that market segment has heritage of trading sessions, participants and rules? If so is there anyone who have done this and set a standard of some sorts?
Best regards,
Erik Scholander
The hierarchy for market segments was mainly driven by OMX who have such market structures. I do not know whether one would attach the rules etc. to the leave nodes or to nodes higher up. This simply depends on your needs and the diversity/granularity of rules etc. that you define. This will be different across markets as the underlying business models naturally differ.
Yet another question on the topic of trading status and similar.
Heritage in market segments. Is there any best practice or recommended
uses for this? According to the Market Definition market segments can be
arranged in a hierarchy (see field 1325). Is the intention that market
segment has heritage of trading sessions, participants and rules? If so
is there anyone who have done this and set a standard of some sorts?Best regards, Erik Scholander
I believe more than one option is required for the messages you send out to convey state. The most common one in use today is to only see the lowest level and issue a state change message per security or contract for every change. This leads to a large number of messages and bursty message flows.
Aggregation of such messages means that the user has to propagate the information down to the lowest level due to the lack of explicit messages. One option is to aggregate the securities to a higher level and send state changes on this level unless an override on the individual security is needed. This applies especially to derivatives where you might not even be able to halt a single series but only all series within given product. There is no FIX message to reflect this aggregation today, so you would have to use the SecurityStatus message and “tweak” the Instrument block with Symbol=“[N/A]” and the usage of fields such as Product or SecurityGroup.
The only level of aggregation that is available is the trading (sub)session through the TradingSessionStatus message. As said before, such a status needs to be implicitly propagated to the security level to avoid having to send explicit security level state changes. You do not really need a value in SecurityTradingStatus that points to the current trading session value. However, if you deviate from the trading session value you also need to send a second explicit message when you want to revert back to it. It is about message flows and telling your users what to expect for which chain of events. For example, should a new trading session status automatically “align” all security status values again or does a deviation on the security level carry on regardless?
To use your example: subsession is pre-trade, security A is set to halt for whatever reason, subsession changes to continuous: should A still be halted or automatically receive the state that the new subsession has?, should A only be halted if another explicit security level halt is issued? These are the kind of questions you need to answer and the driving factors should be low message volume and conceptual simplicity.
The savings you get from using aggregated state change messages typically apply to the opening, closing and halting of (sub)sessions. They represent “instructions” more than anything else (e.g. set all securities in this session to halt).
Regards,
Hanno.
Thank you very much for your reply Hanno! Just as you described, I am
planning on using the sub session ID as the different phases in the
trading sessions, as recommended in the “Best practices”. But more
exactly what is best practice for reporting the SecurityTradingStatus?
To clarify a little more I will explain the problem I am facing
(slightly simplified). My TradingSession “DAY” consists of the phases:
“CLOSED”, “PRE-TRADE”, “TRADE” and “POST-TRADE”. I convey information
that we have entered pre-trade through TradingSessStatus. However during
this phase a request asking for SecurityTradingStatus on a specific
security appears. What should I reply? If I reply the security trading
status is pre-trade, how should the recipient know this is only
temporary (the status should for example not be updated if the security
trading status is “halted” when going from pre-trade to continuous
trading). The solution I have been thinking of is to make a new
SecurityTradeStatus value in the lines of “see trade session status”
(perhaps this is something that should be added and given a default
value if more approve) and only use strictly sequential trading sessions
(hence my question about overlapping trading sessions) or use ‘17’ at
all times unless it should override the trading session status. What do
you think about this solution and does it follow best practice?Thank you in advance! Erik Scholander
Erik,
trading (sub)sessions and states are a complex area as the
requirements are so broad and the delineation between them is blurred.
A (sub)session name can easily be viewed as a state too. It might help
if you see (sub)sessions as planned/scheduled elements (e.g. pre-open
at 8:55am) and states as unforeseen elements (e.g. trading halt due to
excessive price change). Therefore the best practices tried to cover
as much ground as possible without being able to address all
individual cases.SecurityTradingStatus and TradSessStatus contain many different values
today and are in my view not consistent. However it is very hard to
change enum values without knowing who is using them and whose
application one would break. Both fields should be used in a
consistent manner, e.g. the session level overrides the security level
or vice versa depending on the level of restriction. If the session is
halted, the security pertaining to that session cannot be trading but
the security can be halted if the session in general is trading. The
security level should be much more granular than the session level and
will reflect details of auctions for example (freeze, balancing,…).Hope this clarifies it a bit. It is easier if one has a specific
requirement, it is hard to describe generically.Regards, Hanno.