Imported from previous forum
what is standard usage for SecurityTradingEvent(1174) in relation to SecurityTradingStatus(326)…
for example, if 326=3(Resume)… does 1174 describe
- why that security resumed; or
- the previous state of that security; or
- some other “relat[ion]” to 326
the only description for 1174 i am able to find is…
“Identifies an event related to a SecurityTradingStatus(326). An event occurs and is gone, it is not a state that applies for a period of time”
I am not able to ascertain what the correct usage is from this description…
SecurityTradingStatus is the main field here and conveys a change of state for an instrument to a new value. SecurityTradingEvent came later to provide the ability to convey events. It generalizes the previously available field HaltReason(327) which only applies to a subset of state changes.
There are at least two use cases for the presence of SecurityTradingEvent:
- The state change is caused by an event
- There is an event without a change of state
The previous state is not communicated, i.e. the recipient needs to maintain the current state to determine whether there was an actual state change. The definition of states and events depends on the specific market model. States are typically associated with a set of capabilities (e.g. enter/modify/delete orders, matching) and visibilities (e.g. depth, top of book, indicative auction prices). You also have the option to use the two fields TradingSession(Sub)ID to convey a trading phase associated with well defined capabilities and visibilities. FIX tries to provide a framework without prescribing in detail what qualifies as a state/event/(sub)session and what does not.
Regards,
Hanno.
what is standard usage for SecurityTradingEvent(1174) in relation to SecurityTradingStatus(326)…
for example, if 326=3(Resume)… does 1174 describe
- why that security resumed; or
- the previous state of that security; or
- some other “relat[ion]” to 326
the only description for 1174 i am able to find is…
“Identifies an event related to a SecurityTradingStatus(326). An event occurs and is gone, it is not a state that applies for a period of time”I am not able to ascertain what the correct usage is from this description…
I have captured this on FIXwiki at Welcome fixwiki.org - BlueHost.com
SecurityTradingStatus is the main field here and conveys a change of state for an instrument to a new value. SecurityTradingEvent came later to provide the ability to convey events. It generalizes the previously available field HaltReason(327) which only applies to a subset of state changes.
There are at least two use cases for the presence of SecurityTradingEvent:
- The state change is caused by an event
- There is an event without a change of state
The previous state is not communicated, i.e. the recipient needs to maintain the current state to determine whether there was an actual state change. The definition of states and events depends on the specific market model. States are typically associated with a set of capabilities (e.g. enter/modify/delete orders, matching) and visibilities (e.g. depth, top of book, indicative auction prices). You also have the option to use the two fields TradingSession(Sub)ID to convey a trading phase associated with well defined capabilities and visibilities. FIX tries to provide a framework without prescribing in detail what qualifies as a state/event/(sub)session and what does not.
Regards,
Hanno.what is standard usage for SecurityTradingEvent(1174) in relation to SecurityTradingStatus(326)…
for example, if 326=3(Resume)… does 1174 describe
- why that security resumed; or
- the previous state of that security; or
- some other “relat[ion]” to 326
the only description for 1174 i am able to find is…
“Identifies an event related to a SecurityTradingStatus(326). An event occurs and is gone, it is not a state that applies for a period of time”I am not able to ascertain what the correct usage is from this description…
thanks Hanno / John… i understand now…
I have captured this on FIXwiki at Welcome fixwiki.org - BlueHost.com
SecurityTradingStatus is the main field here and conveys a change of state for an instrument to a new value. SecurityTradingEvent came later to provide the ability to convey events. It generalizes the previously available field HaltReason(327) which only applies to a subset of state changes.
There are at least two use cases for the presence of SecurityTradingEvent:
- The state change is caused by an event
- There is an event without a change of state
The previous state is not communicated, i.e. the recipient needs to maintain the current state to determine whether there was an actual state change. The definition of states and events depends on the specific market model. States are typically associated with a set of capabilities (e.g. enter/modify/delete orders, matching) and visibilities (e.g. depth, top of book, indicative auction prices). You also have the option to use the two fields TradingSession(Sub)ID to convey a trading phase associated with well defined capabilities and visibilities. FIX tries to provide a framework without prescribing in detail what qualifies as a state/event/(sub)session and what does not.
Regards,
Hanno.what is standard usage for SecurityTradingEvent(1174) in relation to SecurityTradingStatus(326)…
for example, if 326=3(Resume)… does 1174 describe
- why that security resumed; or
- the previous state of that security; or
- some other “relat[ion]” to 326
the only description for 1174 i am able to find is…
“Identifies an event related to a SecurityTradingStatus(326). An event occurs and is gone, it is not a state that applies for a period of time”I am not able to ascertain what the correct usage is from this description…