Imported from previous forum
[ original email was from John Armstrong - johna@ms.com ]
A number of exchanges and crossing networks
having multiple crossing sessions throughout the
day. For example:
o ITG/Posit has six sesssions throughout the day.
o NYSE has end of day 1 and 2 sided crossing sessions
o Xetra in Germany has midday crossing sessions for oddlot orders
o Tokyo Stock Exchange has two crossing sessions
while the market is closed(TOSTNET).
I think it would be useful to have an additional TimeInForce enum of CrossingSession and an additional tag called CrossingSessionID, the values of which would be defined by the exchange
(e.g. POSIT1,2,3-6; NYSE_1_SIDE, XET_MIDDAY, etc).
This would allow orders to be sent down the same line with being confused with typical Day orders.
CrossingSessionID (and TimeInForce) would be on
orders/cancel/cancelreplace as well as execution and cancel reject messages.
Would this satisfy the requirements of other exchanges w.r.t crossing sessions?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I think it would be useful to have an additional TimeInForce enum of CrossingSession and an additional tag called CrossingSessionID, the values of which would be defined by the exchange
> (e.g. POSIT1,2,3-6; NYSE_1_SIDE, XET_MIDDAY, etc).
>
> This would allow orders to be sent down the same line with being confused with typical Day orders.
>
> CrossingSessionID (and TimeInForce) would be on
> orders/cancel/cancelreplace as well as execution and cancel reject messages.
>
> Would this satisfy the requirements of other exchanges w.r.t crossing sessions?
>
I’ve done some thinking about that same issue and came up with a somewhat different way of doing it.
Have a GoodFrom time field in FIX. GoodFrom can be used in conjuction with pretty much any TimeInForce. One could put in an order at 3:50 PM with a GoodFrom field of 4:00 PM, TimeInForce of GoodTillDate, and ExpireTime 5:00 PM, and it would be valid just for that session or sessions lying in that time frame.
This is advantageous because:
-
It allows for additional functionality. One could say, at 12:45 PM I want to buy this at market, day, or specify a range of time in the future during which an order should be live.
-
It doesn’t require keeping a central enumeration of every exchange’s trading and crossing sessions.
-
It is easy to let an order span multiple trading sessions.
The main disadvantage I see is that it doesn’t allow specification of which session an order should be placed in, but I’d think that in most cases it should be obvious by the order itself, such as the case of a simultaneous odd lot and round lot crossing session.
When such an order goes in with a GoodFrom time field in the future, then there’s an issue of what OrdStatus to send back. Possible approaches I see are:
-
Send back nothing when the order is placed, and send New when the GoodFrom time hits. I don’t like this because one doesn’t immediately know if the order passed initial validation checks or somehow got lost.
-
Send back either Pending New or Suspended when the order is placed and passes validation checks. Send back New when the "GoodFrom" time hits.
" Send back New once the order has been placed and passed validation checks. Send nothing when the “GoodFrom” time hits. This can be advantageous as it doesn’t mean sending back a whole mess of executions right at the open of a session confirming orders as live in the session.
[ original email was from Satoru Mizukami - satoru.mizukami@nssmb.com ]
Isn’t it much easier to divide the story into before execution and execution, is it ?
In execution or later stage , market information exists as the fact to be kept.
( at least as far as in Japan )
So maybe we need some additional field to express it.
( such as CrossingSessionID or so. )
But in before execution stage, as you mentioned,
the other type of expression of market will be also convenient for executing smoothly.
I feel the meaning of market information in the order message could be
different from that in the execution message.
> > I think it would be useful to have an additional TimeInForce enum of CrossingSession and an additional tag called CrossingSessionID, the values of which would be defined by the exchange
> > (e.g. POSIT1,2,3-6; NYSE_1_SIDE, XET_MIDDAY, etc).
> >
> > This would allow orders to be sent down the same line with being confused with typical Day orders.
> >
> > CrossingSessionID (and TimeInForce) would be on
> > orders/cancel/cancelreplace as well as execution and cancel reject messages.
> >
> > Would this satisfy the requirements of other exchanges w.r.t crossing sessions?
> >
>
> I’ve done some thinking about that same issue and came up with a somewhat different way of doing it.
>
> Have a GoodFrom time field in FIX. GoodFrom can be used in conjuction with pretty much any TimeInForce. One could put in an order at 3:50 PM with a GoodFrom field of 4:00 PM, TimeInForce of GoodTillDate, and ExpireTime 5:00 PM, and it would be valid just for that session or sessions lying in that time frame.
>
> This is advantageous because:
>
> * It allows for additional functionality. One could say, at 12:45 PM I want to buy this at market, day, or specify a range of time in the future during which an order should be live.
>
> * It doesn’t require keeping a central enumeration of every exchange’s trading and crossing sessions.
>
> * It is easy to let an order span multiple trading sessions.
>
> The main disadvantage I see is that it doesn’t allow specification of which session an order should be placed in, but I’d think that in most cases it should be obvious by the order itself, such as the case of a simultaneous odd lot and round lot crossing session.
>
> When such an order goes in with a GoodFrom time field in the future, then there’s an issue of what OrdStatus to send back. Possible approaches I see are:
>
> * Send back nothing when the order is placed, and send New when the GoodFrom time hits. I don’t like this because one doesn’t immediately know if the order passed initial validation checks or somehow got lost.
>
> * Send back either Pending New or Suspended when the order is placed and passes validation checks. Send back New when the “GoodFrom” time hits.
>
> " Send back New once the order has been placed and passed validation checks. Send nothing when the “GoodFrom” time hits. This can be advantageous as it doesn’t mean sending back a whole mess of executions right at the open of a session confirming orders as live in the session.
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I feel the meaning of market information in the order message could be
> different from that in the execution message.
This makes a lot of sense, as it seems to follow in the previous design philosophy of FIX that the firm placing the order should be insulated from the various idiosyncrasies of each exchange or ECN, such as was done with the concept of an "Order Modification" instead of a separate "Cancel Replace" and "Cancel Leaves."
It seems like a reasonable approach to make a character SessionID field in an Execution, Advertsement and Allocation message, which the exchange populates with its own identifier for the trading or crossing session in question. This way one wouldn’t run into the problem of having one’s order rejected because CROSSING_SESSION_2 was specified when it should have been CROSSING_SESSION_3, even though the trader wants the 3:15 to 4:00 PM session and doesn’t care what it is called. Having the exchange specify free-form text to identify the session allows one to database the field for human-readable diagnostic purposes and possibly to group trades in each session together for allocations, all without having to constantly maintain an updated set of enumerations for each trading partner’s sessions.
Note that there is an existing field in the 4.1 spec called EffectiveTime (tag 168) which could serve as "GoodFromDate" as Ryan describes. This field is not currently part of the Order messages but is probably a better name than GoodFromDate. This seems like a viable approach.
> > I think it would be useful to have an additional TimeInForce enum of CrossingSession and an additional tag called CrossingSessionID, the values of which would be defined by the exchange
> > (e.g. POSIT1,2,3-6; NYSE_1_SIDE, XET_MIDDAY, etc).
> >
> > This would allow orders to be sent down the same line with being confused with typical Day orders.
> >
> > CrossingSessionID (and TimeInForce) would be on
> > orders/cancel/cancelreplace as well as execution and cancel reject messages.
> >
> > Would this satisfy the requirements of other exchanges w.r.t crossing sessions?
> >
>
> I’ve done some thinking about that same issue and came up with a somewhat different way of doing it.
>
> Have a GoodFrom time field in FIX. GoodFrom can be used in conjuction with pretty much any TimeInForce. One could put in an order at 3:50 PM with a GoodFrom field of 4:00 PM, TimeInForce of GoodTillDate, and ExpireTime 5:00 PM, and it would be valid just for that session or sessions lying in that time frame.
>
> This is advantageous because:
>
> * It allows for additional functionality. One could say, at 12:45 PM I want to buy this at market, day, or specify a range of time in the future during which an order should be live.
>
> * It doesn’t require keeping a central enumeration of every exchange’s trading and crossing sessions.
>
> * It is easy to let an order span multiple trading sessions.
>
> The main disadvantage I see is that it doesn’t allow specification of which session an order should be placed in, but I’d think that in most cases it should be obvious by the order itself, such as the case of a simultaneous odd lot and round lot crossing session.
>
> When such an order goes in with a GoodFrom time field in the future, then there’s an issue of what OrdStatus to send back. Possible approaches I see are:
>
> * Send back nothing when the order is placed, and send New when the GoodFrom time hits. I don’t like this because one doesn’t immediately know if the order passed initial validation checks or somehow got lost.
>
> * Send back either Pending New or Suspended when the order is placed and passes validation checks. Send back New when the “GoodFrom” time hits.
>
> " Send back New once the order has been placed and passed validation checks. Send nothing when the “GoodFrom” time hits. This can be advantageous as it doesn’t mean sending back a whole mess of executions right at the open of a session confirming orders as live in the session.
>
>