Concept of FIX protocol regarding New Order / Cancel Order

[chichihhuang_x]

Imported from previous forum

[chichihhuang_x]

Dear Experts,

Recently, i have a question regarding to the FIX. Forgive me, if my question doesn’t make sense.

Scenario: If i have two physical FIX Gateway servers and both connect to the same front-end trading system.

1. I place a new single order via FIX GW 1 to front-end trading system and then send to the Exchange. I will send a unique ClOrdID=C001 and will get an Execution report of ClOrdID=C001 and OrdNo=001.

2. Now i want to cancel the order via FIX GW 2 and send to front-end trading system and then to the Exchange. I will send an unqiue ClOrdID=C002, OrgClOrdID=C001, and OrdNo=001 to the FIX GW 2.

From my understanding of the FIX protocol, the FIX protocol itself is just a order routing Gateway, therefore, the previous mention scenario should be valid.
However, i got an issue with a vendor. They think that the previous scenario is not the standard FIX behaviour. They think that the new order and cancel order can only accept via FIX GW 1.

Hope any one can help me to clarify of this FIX protocol behaviour which one is correct? or actually this is defined by user need, both of us are correct?

Thanks.

[deepakvaishnav_x]

if Both FIXGATEWAYS are in HA(High Availablity) mode below one is achivable.

here the problems comes as FIXGW also maintains Orders in their database and when you try to cancel the order via FIXGW-2, it has no information of that particualar order in its database and will result into order not found exception .

Thanks
Deepak

Dear Experts,

Recently, i have a question regarding to the FIX. Forgive me, if my question doesn’t make sense.

Scenario: If i have two physical FIX Gateway servers and both connect to the same front-end trading system.

1. I place a new single order via FIX GW 1 to front-end trading system and then send to the Exchange. I will send a unique ClOrdID=C001 and will get an Execution report of ClOrdID=C001 and OrdNo=001.

2. Now i want to cancel the order via FIX GW 2 and send to front-end trading system and then to the Exchange. I will send an unqiue ClOrdID=C002, OrgClOrdID=C001, and OrdNo=001 to the FIX GW 2.

From my understanding of the FIX protocol, the FIX protocol itself is just a order routing Gateway, therefore, the previous mention scenario should be valid.
However, i got an issue with a vendor. They think that the previous scenario is not the standard FIX behaviour. They think that the new order and cancel order can only accept via FIX GW 1.

Hope any one can help me to clarify of this FIX protocol behaviour which one is correct? or actually this is defined by user need, both of us are correct?

Thanks.

[hanno.klein]

You make an assumption of a stateful FIX Gateway that is only aware of the orders that were once entered through it. The issue here goes beyond having two FIX Gateways. It is the general problem of having more than one interface to access the same entity (order/quote) on an exchange. You could have a mix of a legacy interface and a FIX interface. It is a non-trivial scenario and I do not blame the vendor for limiting the scope of an order to the session entering it.
However, there is no limitation from a FIX perspective to do that, especially if a second FIX Gateway is supposed to be the backup in a failover scenario. If this is supported then both need to be fully aware of all orders which requires them to communicate, e.g. to provide drop copies of ExecutionReports to one another.
ClOrdID values are a special problem of such scenarios as you either need to guarantee that they never overlap for requests sent to the FIX Gateway or you need to use OrderID for uniqueness instead. FIX does not require to keep ClOrdID values distinct across sessions.
See EEWG Recommended Best Practices, Chapter 3.2.3 Order Entry and Modification from Different Sources (http://fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf) for a discussion of the problem raised in this thread.

if Both FIXGATEWAYS are in HA(High Availablity) mode below one is achivable.

here the problems comes as FIXGW also maintains Orders in their database and when you try to cancel the order via FIXGW-2, it has no information of that particualar order in its database and will result into order not found exception .

Thanks
Deepak

Dear Experts,

Recently, i have a question regarding to the FIX. Forgive me, if my question doesn’t make sense.

Scenario: If i have two physical FIX Gateway servers and both connect to the same front-end trading system.

1. I place a new single order via FIX GW 1 to front-end trading system and then send to the Exchange. I will send a unique ClOrdID=C001 and will get an Execution report of ClOrdID=C001 and OrdNo=001.

2. Now i want to cancel the order via FIX GW 2 and send to front-end trading system and then to the Exchange. I will send an unqiue ClOrdID=C002, OrgClOrdID=C001, and OrdNo=001 to the FIX GW 2.

From my understanding of the FIX protocol, the FIX protocol itself is just a order routing Gateway, therefore, the previous mention scenario should be valid.
However, i got an issue with a vendor. They think that the previous scenario is not the standard FIX behaviour. They think that the new order and cancel order can only accept via FIX GW 1.

Hope any one can help me to clarify of this FIX protocol behaviour which one is correct? or actually this is defined by user need, both of us are correct?

Thanks.

[chichihhuang_x]

I tried to download the file which you recommend, but failed.
An other place that i can download from to take a look at the pdf?

See EEWG Recommended Best Practices, Chapter 3.2.3 Order Entry and Modification from Different Sources (http://fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf) for a discussion of the problem raised in this thread.

Thanks.

Chi-Chih Huang

You make an assumption of a stateful FIX Gateway that is only aware of the orders that were once entered through it. The issue here goes beyond having two FIX Gateways. It is the general problem of having more than one interface to access the same entity (order/quote) on an exchange. You could have a mix of a legacy interface and a FIX interface. It is a non-trivial scenario and I do not blame the vendor for limiting the scope of an order to the session entering it.
However, there is no limitation from a FIX perspective to do that, especially if a second FIX Gateway is supposed to be the backup in a failover scenario. If this is supported then both need to be fully aware of all orders which requires them to communicate, e.g. to provide drop copies of ExecutionReports to one another.
ClOrdID values are a special problem of such scenarios as you either need to guarantee that they never overlap for requests sent to the FIX Gateway or you need to use OrderID for uniqueness instead. FIX does not require to keep ClOrdID values distinct across sessions.
See EEWG Recommended Best Practices, Chapter 3.2.3 Order Entry and Modification from Different Sources (http://fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf) for a discussion of the problem raised in this thread.

if Both FIXGATEWAYS are in HA(High Availablity) mode below one is achivable.

here the problems comes as FIXGW also maintains Orders in their database and when you try to cancel the order via FIXGW-2, it has no information of that particualar order in its database and will result into order not found exception .

Thanks
Deepak

Dear Experts,

Recently, i have a question regarding to the FIX. Forgive me, if my question doesn’t make sense.

Scenario: If i have two physical FIX Gateway servers and both connect to the same front-end trading system.

1. I place a new single order via FIX GW 1 to front-end trading system and then send to the Exchange. I will send a unique ClOrdID=C001 and will get an Execution report of ClOrdID=C001 and OrdNo=001.

2. Now i want to cancel the order via FIX GW 2 and send to front-end trading system and then to the Exchange. I will send an unqiue ClOrdID=C002, OrgClOrdID=C001, and OrdNo=001 to the FIX GW 2.

From my understanding of the FIX protocol, the FIX protocol itself is just a order routing Gateway, therefore, the previous mention scenario should be valid.
However, i got an issue with a vendor. They think that the previous scenario is not the standard FIX behaviour. They think that the new order and cancel order can only accept via FIX GW 1.

Hope any one can help me to clarify of this FIX protocol behaviour which one is correct? or actually this is defined by user need, both of us are correct?

Thanks.

[chichihhuang_x]

Downloaded the file and read it.

Understand that when supporting FIX and non-FIX at the same time, would face the same problem as well.

Thanks.

Chi-Chih Huang

I tried to download the file which you recommend, but failed.
An other place that i can download from to take a look at the pdf?

See EEWG Recommended Best Practices, Chapter 3.2.3 Order Entry and Modification from Different Sources (http://fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf) for a discussion of the problem raised in this thread.

Thanks.

Chi-Chih Huang

You make an assumption of a stateful FIX Gateway that is only aware of the orders that were once entered through it. The issue here goes beyond having two FIX Gateways. It is the general problem of having more than one interface to access the same entity (order/quote) on an exchange. You could have a mix of a legacy interface and a FIX interface. It is a non-trivial scenario and I do not blame the vendor for limiting the scope of an order to the session entering it.
However, there is no limitation from a FIX perspective to do that, especially if a second FIX Gateway is supposed to be the backup in a failover scenario. If this is supported then both need to be fully aware of all orders which requires them to communicate, e.g. to provide drop copies of ExecutionReports to one another.
ClOrdID values are a special problem of such scenarios as you either need to guarantee that they never overlap for requests sent to the FIX Gateway or you need to use OrderID for uniqueness instead. FIX does not require to keep ClOrdID values distinct across sessions.
See EEWG Recommended Best Practices, Chapter 3.2.3 Order Entry and Modification from Different Sources (http://fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf) for a discussion of the problem raised in this thread.

if Both FIXGATEWAYS are in HA(High Availablity) mode below one is achivable.

here the problems comes as FIXGW also maintains Orders in their database and when you try to cancel the order via FIXGW-2, it has no information of that particualar order in its database and will result into order not found exception .

Thanks
Deepak

Dear Experts,

Recently, i have a question regarding to the FIX. Forgive me, if my question doesn’t make sense.

Scenario: If i have two physical FIX Gateway servers and both connect to the same front-end trading system.

1. I place a new single order via FIX GW 1 to front-end trading system and then send to the Exchange. I will send a unique ClOrdID=C001 and will get an Execution report of ClOrdID=C001 and OrdNo=001.

2. Now i want to cancel the order via FIX GW 2 and send to front-end trading system and then to the Exchange. I will send an unqiue ClOrdID=C002, OrgClOrdID=C001, and OrdNo=001 to the FIX GW 2.

From my understanding of the FIX protocol, the FIX protocol itself is just a order routing Gateway, therefore, the previous mention scenario should be valid.
However, i got an issue with a vendor. They think that the previous scenario is not the standard FIX behaviour. They think that the new order and cancel order can only accept via FIX GW 1.

Hope any one can help me to clarify of this FIX protocol behaviour which one is correct? or actually this is defined by user need, both of us are correct?

Thanks.

[chichihhuang_x]

I’m hoping to use FIX GATEWAYS in HA mode.
The actual order control is done at the front-end trading system.
The FIX GATEWAY that the vendor provide is just a channel sending order to this front-end trading system.

Once the new order request (ClOrdID=C001) send to FIX GW 1 and to the front-end trading system. The front-end trading system will send back an OrdNo (001) along with the ClOrdID (C001).

Therefore when I cancel order via FIX-GW 2, the actual control still need to depend on the front-end trading system.

I was wondering if this FIX protocol is suitable for HA mode?

Thanks.

Chi-Chih Huang

if Both FIXGATEWAYS are in HA(High Availablity) mode below one is achivable.

here the problems comes as FIXGW also maintains Orders in their database and when you try to cancel the order via FIXGW-2, it has no information of that particualar order in its database and will result into order not found exception .

Thanks
Deepak

Dear Experts,

Recently, i have a question regarding to the FIX. Forgive me, if my question doesn’t make sense.

Scenario: If i have two physical FIX Gateway servers and both connect to the same front-end trading system.

1. I place a new single order via FIX GW 1 to front-end trading system and then send to the Exchange. I will send a unique ClOrdID=C001 and will get an Execution report of ClOrdID=C001 and OrdNo=001.

2. Now i want to cancel the order via FIX GW 2 and send to front-end trading system and then to the Exchange. I will send an unqiue ClOrdID=C002, OrgClOrdID=C001, and OrdNo=001 to the FIX GW 2.

From my understanding of the FIX protocol, the FIX protocol itself is just a order routing Gateway, therefore, the previous mention scenario should be valid.
However, i got an issue with a vendor. They think that the previous scenario is not the standard FIX behaviour. They think that the new order and cancel order can only accept via FIX GW 1.

Hope any one can help me to clarify of this FIX protocol behaviour which one is correct? or actually this is defined by user need, both of us are correct?

Thanks.

[hanno.klein]

The FIX Protocol definitely works for high performance and high availability scenarios. FIX 5 may work better than FIX 4.x due to Transport Independence being available.

I was wondering if this FIX protocol is suitable for HA mode?

[johnpeng13_x]

If your intent was to use your “FIX Gateway” as a “pure gateway” (i.e. a stateless interface), then I don’t think it’d be necessary for the orginal order and the cancel to be sent via a same gateway instance.

However, it’s not uncommon that some commercial FIX offerings also provide add-on features requiring that the order history be maintained. For example, your “FIX Gateway” may be expected to carry out some “risk/compliance filtering” to control, say, the “accumulated exposure”. In this case, unless the two gateways have a “shared memory” of the order history, you won’t be able to send the cancel via a separate gateway without breaking that add-on feature.

In summary, the answer to your question doesn’t reside on the FIX protocol itself, but rather on how your gateways are configured, and what functionalities do you expect them to deliver.

Hope this helps…

Dear Experts,

Recently, i have a question regarding to the FIX. Forgive me, if my question doesn’t make sense.

Scenario: If i have two physical FIX Gateway servers and both connect to the same front-end trading system.

1. I place a new single order via FIX GW 1 to front-end trading system and then send to the Exchange. I will send a unique ClOrdID=C001 and will get an Execution report of ClOrdID=C001 and OrdNo=001.

2. Now i want to cancel the order via FIX GW 2 and send to front-end trading system and then to the Exchange. I will send an unqiue ClOrdID=C002, OrgClOrdID=C001, and OrdNo=001 to the FIX GW 2.

From my understanding of the FIX protocol, the FIX protocol itself is just a order routing Gateway, therefore, the previous mention scenario should be valid.
However, i got an issue with a vendor. They think that the previous scenario is not the standard FIX behaviour. They think that the new order and cancel order can only accept via FIX GW 1.

Hope any one can help me to clarify of this FIX protocol behaviour which one is correct? or actually this is defined by user need, both of us are correct?

Thanks.