Imported from previous forum
I would appreciate if someone can help me find some guidelines that FIX states on the values that I can send in Tag 150 of an Execution Report.
We have an Order Management System and the client has placed an Order that is valid up to a given date. If the order remains un-filled till the end of trading on the last validity date, we send out an execution report at the close of business that the Order has expired. Is it ok to send the Tag 150 as H (Trade Cancel), Order Status (tag 39) as C or should we send out Tag 150 as 0?
What should we send if we manually cancel the order in our system. We currently send 150 as H (Trade Cancel) and Order Status as 4 (Canceled) but we are told that this is not FIX complaint and we should send Tag 150 as 0.
Any help or reference material will be appreciated.
Thanks
I would appreciate if someone can help me find some guidelines that FIX states on the values that I can send in Tag 150 of an Execution Report.
We have an Order Management System and the client has placed an Order that is valid up to a given date. If the order remains un-filled till the end of trading on the last validity date, we send out an execution report at the close of business that the Order has expired. Is it ok to send the Tag 150 as H (Trade Cancel), Order Status (tag 39) as C or should we send out Tag 150 as 0?
What should we send if we manually cancel the order in our system. We currently send 150 as H (Trade Cancel) and Order Status as 4 (Canceled) but we are told that this is not FIX complaint and we should send Tag 150 as 0.
In general it’s best to send the client whatever they ask for. I find it usually works best to work to the client’s expectations rather than strictly to the spec. It is often the case that a buy-side client cannot easily change the behaviour of their OMS to suit you.
Peter,
I couldn’t let that one stand without comment. You are right that in the end it is the client with the order flow who has the power to make you violate the standard to avoid losing the business. However, it is a quick win for the client without seeing the detrimental effect on the industry as a whole which will ultimately impact the client as he has to pay more to support all these dialects.
The serious attempt needs to be made to comply with the FIX standard and deviations should be a conscious decision to avoid a major cost impact. This is especially important whenever a new application is built and one has the chance to migrate away from non-compliant old versions. FIX starts within the core application and not when you start building an interface on top of it.
FIX has a high degree of flexibility to support various flows for different asset classes and user environments. There is no need to come up with even more ways to do the same thing. With the increased scrutiny of regulators there will be more incentives to use standards and to use them the way they were intended to be used. The regulator will not accept a reporting standard that comes in 100 different flavors to him. This will only create the perception that it is actually not a standard and encourage the regulator to come up with his own “standard” that everybody has to comply with. You cannot threaten to report to somebody else if the regulator does not want to take your flavor of messages 
Regards,
Hanno.
In general it’s best to send the client whatever they ask for. I find it usually works best to work to the client’s expectations rather than strictly to the spec. It is often the case that a buy-side client cannot easily change the behaviour of their OMS to suit you.
Hi Hanno,
I appreciate what you’re saying, but back in the real world, when Connectivity Sales ask ‘Why aren’t we live with BigHedgeFund yet?’ answering ‘Because their OMS doesn’t comply with the FIX spec, we’re waiting for them to fix it’ is not an option.
I’ve spent a significant part of my career adapting sell-side trading systems to suit non-standard behaviour of client OMSs. Obviously where you both have scope to change code then there is no question that you will follow the FIX spec to the letter, but as I said, a significant proportion of buy-side firms do not have the ability to change the behaviour of their systems and if you want their business then all you can do is point out the issues to them, and then give them what they need.
Regards,
Peter
Peter,
I couldn’t let that one stand without comment. You are right that in the end it is the client with the order flow who has the power to make you violate the standard to avoid losing the business. However, it is a quick win for the client without seeing the detrimental effect on the industry as a whole which will ultimately impact the client as he has to pay more to support all these dialects.
The serious attempt needs to be made to comply with the FIX standard and deviations should be a conscious decision to avoid a major cost impact. This is especially important whenever a new application is built and one has the chance to migrate away from non-compliant old versions. FIX starts within the core application and not when you start building an interface on top of it.
FIX has a high degree of flexibility to support various flows for different asset classes and user environments. There is no need to come up with even more ways to do the same thing. With the increased scrutiny of regulators there will be more incentives to use standards and to use them the way they were intended to be used. The regulator will not accept a reporting standard that comes in 100 different flavors to him. This will only create the perception that it is actually not a standard and encourage the regulator to come up with his own “standard” that everybody has to comply with. You cannot threaten to report to somebody else if the regulator does not want to take your flavor of messages
Regards,
Hanno.In general it’s best to send the client whatever they ask for. I find it usually works best to work to the client’s expectations rather than strictly to the spec. It is often the case that a buy-side client cannot easily change the behaviour of their OMS to suit you.
The use of trade cancel order status seems inconsistent with the Spec (pg 11 Vol 4) “Communication of information about a new fill is via the Execution report with ExecType = Trade. Execution Reports with ExecType = Trade Cancel or Trade Correct are used to cancel or correct a previously modified execution report”
Pg 46 shows the Order State Matrices and is worth a look.
4.4 doesn’t have explicit examples of your cases in this section however Fixmate says this about tag 150 “Describes the specific ExecutionRpt (i.e. Pending Cancel) while OrdStatus (39) will always identify the current order status (i.e. Partially Filled” which suggests that in your example Q1) the following applies:
Q1) > We have an Order Management System and the client has placed an Order that is valid up to a given date. If the order remains un-filled till the end of trading on the last validity date, we send out an execution report at the close of business that the Order has expired. Is it ok to send the Tag 150 as H (Trade Cancel), Order Status (tag 39) as C or should we send out Tag 150 as 0?
A1) >> The notification should carry 39=C(expired) 150=C(expired)
Pg 50 Section B, Cancelled Orders, of the Order State Matrices suggests the following for your Q2):
Q2) > What should we send if we manually cancel the order in our system. We currently send 150 as H (Trade Cancel) and Order Status as 4 (Canceled) but we are told that this is not FIX complaint and we should send Tag 150 as 0.
A2) >> The notification should carry 39=4 (cancelled) and 150=4 (cancelled).
I’d also note that doing whatever the client asks for isn’t the best way forward and will make more work for your firm in the longer term and kinda defeat the object of having an industry standard, but do recognise the reality that this doesn’t always happen.
I would appreciate if someone can help me find some guidelines that FIX states on the values that I can send in Tag 150 of an Execution Report.
We have an Order Management System and the client has placed an Order that is valid up to a given date. If the order remains un-filled till the end of trading on the last validity date, we send out an execution report at the close of business that the Order has expired. Is it ok to send the Tag 150 as H (Trade Cancel), Order Status (tag 39) as C or should we send out Tag 150 as 0?
What should we send if we manually cancel the order in our system. We currently send 150 as H (Trade Cancel) and Order Status as 4 (Canceled) but we are told that this is not FIX complaint and we should send Tag 150 as 0.
Any help or reference material will be appreciated.
Thanks
I would like to start by pointing out that the title of this thread is misleading. ExecTransType is tag 20 and not 150 and was deprecated as of FIX 4.3. Tag 150 is ExecType and the values you show are from ExecType.
Cancellation of unfilled orders at expiration:
An order is not a trade and ExecType values F,G,H are all about trades and not about orders. H cancels a trade and not an order. ExecType values 0,4,5 are the standard ones for orders (New, Canceled, Replaced). However, New and Replaced are used in response to a request from the order submitter. Unsolicited actions from the order receiver use ExecType D=Restated unless there is an explicit value. Restatement imply that the order is still active but that one or more of its attributes have changed. Examples for exceptions that are stop orders being triggered (ExecType L), order has expired (ExecType C) or also order has been canceled (ExecType 4). There is a debate whether it is better to send an explicit expiry, an unsolicited cancel or a restatement of active orders on the next business day (implicit cancel) but that should depend on your counterparty.
Your idea of using ExecType 0=New sounds to me like you are mixing ExecType and ExecTransType where “new” information is always sent with ExecTransType 0=New. ExecType expresses the purpose of the ExecutionReport and 0=New only applies to new orders and cannot apply to existing orders that are cancelled. OrdStatus expresses the status of the order entity, i.e. C=Expired works.
Manual order cancellation by order receiver:
Again you are referring to advice given to you to send tag 150 as 0=New. This clearly refers to tag 20 ExecTransType 0=New and is correct for FIX 4.2. It is not correct for FIX 4.4. Tag 20 is 0=New as long as you send out new information and do not have to change or withdraw something you sent before. This is a different concept which is only valid up to FIX 4.2.
A manual order cancellation should be called “unsolicited cancel” to make clear that it is not the order submitter who is manually cancelling the order prior to its expiry or complete fill. ExecType H=Trade cancel is not correct as you are not cancelling a trade involving the order. You should send ExecType 4=Cancelled and OrdType 4=Cancelled.
Have a look at FIX Spec Volume 4, Order State Change Matrices where you will find examples of many different flows with ExecType and OrdStatus.
Regards,
Hanno.
I would appreciate if someone can help me find some guidelines that FIX states on the values that I can send in Tag 150 of an Execution Report.
We have an Order Management System and the client has placed an Order that is valid up to a given date. If the order remains un-filled till the end of trading on the last validity date, we send out an execution report at the close of business that the Order has expired. Is it ok to send the Tag 150 as H (Trade Cancel), Order Status (tag 39) as C or should we send out Tag 150 as 0?
What should we send if we manually cancel the order in our system. We currently send 150 as H (Trade Cancel) and Order Status as 4 (Canceled) but we are told that this is not FIX complaint and we should send Tag 150 as 0.
Any help or reference material will be appreciated.
Thanks
Thanks a lot for the responses. Things are clearer now and I apologize for the mismatch between the tag and the name I put in the subject of this thread. I was indeed talking about ExecType and tag 150.
Thanks
I would like to start by pointing out that the title of this thread is misleading. ExecTransType is tag 20 and not 150 and was deprecated as of FIX 4.3. Tag 150 is ExecType and the values you show are from ExecType.
Cancellation of unfilled orders at expiration:
An order is not a trade and ExecType values F,G,H are all about trades and not about orders. H cancels a trade and not an order. ExecType values 0,4,5 are the standard ones for orders (New, Canceled, Replaced). However, New and Replaced are used in response to a request from the order submitter. Unsolicited actions from the order receiver use ExecType D=Restated unless there is an explicit value. Restatement imply that the order is still active but that one or more of its attributes have changed. Examples for exceptions that are stop orders being triggered (ExecType L), order has expired (ExecType C) or also order has been canceled (ExecType 4). There is a debate whether it is better to send an explicit expiry, an unsolicited cancel or a restatement of active orders on the next business day (implicit cancel) but that should depend on your counterparty.
Your idea of using ExecType 0=New sounds to me like you are mixing ExecType and ExecTransType where “new” information is always sent with ExecTransType 0=New. ExecType expresses the purpose of the ExecutionReport and 0=New only applies to new orders and cannot apply to existing orders that are cancelled. OrdStatus expresses the status of the order entity, i.e. C=Expired works.Manual order cancellation by order receiver:
Again you are referring to advice given to you to send tag 150 as 0=New. This clearly refers to tag 20 ExecTransType 0=New and is correct for FIX 4.2. It is not correct for FIX 4.4. Tag 20 is 0=New as long as you send out new information and do not have to change or withdraw something you sent before. This is a different concept which is only valid up to FIX 4.2.
A manual order cancellation should be called “unsolicited cancel” to make clear that it is not the order submitter who is manually cancelling the order prior to its expiry or complete fill. ExecType H=Trade cancel is not correct as you are not cancelling a trade involving the order. You should send ExecType 4=Cancelled and OrdType 4=Cancelled.Have a look at FIX Spec Volume 4, Order State Change Matrices where you will find examples of many different flows with ExecType and OrdStatus.
Regards,
Hanno.I would appreciate if someone can help me find some guidelines that FIX states on the values that I can send in Tag 150 of an Execution Report.
We have an Order Management System and the client has placed an Order that is valid up to a given date. If the order remains un-filled till the end of trading on the last validity date, we send out an execution report at the close of business that the Order has expired. Is it ok to send the Tag 150 as H (Trade Cancel), Order Status (tag 39) as C or should we send out Tag 150 as 0?
What should we send if we manually cancel the order in our system. We currently send 150 as H (Trade Cancel) and Order Status as 4 (Canceled) but we are told that this is not FIX complaint and we should send Tag 150 as 0.
Any help or reference material will be appreciated.
Thanks