Imported from previous forum
Hello.
We are designing a solution for a client, and it involves a workflow that we have not supported before. There will be two-way Order messaging between us and the client. We will maintain a database with a front end, and our client will have a database they want synched with ours. Orders can also be created electronically in their database, and sent to us.
When an Order is created in our system, we will send MsgType=D to them. The other messages involved will be Order Cancel Request (F), Order Cancel/Replace (G) and ultimately Trades. The client wants all Acks to use the Execution Report (8). Reject messages will be Order Cancel Reject (9).
I believe all we need to do is correctly chain the orders via the correct Tags. Every Order will have 2 Order Numbers, one from our system and one from theirs. Also, we will need to store their internal order number and they will need to store ours.
So this could be an example flow:
- Order created in our system (X):
MsgType(35)=D
ClOrdID(11)=Xorder01
…
- Ack back from client (Y):
MsgType(35)=8
ClOrdID(11)=Xorder01
OrderID(37)=Yorder01
…
From this point on, no matter who sends an F or G to who these 2 tags will always stay the same:
ClOrdID(11)=Xorder01
OrderID(37)=Yorder01
Am I correct is saying that whoever creates the Order ‘owns’ the 11 tag from then on? When they create an Order the above flow will be the same, and we must store whatever they send us in their 11 and use it going forward for any changes made in our system?
Is there any way around this? I know the client is not going to be thrilled about adding a column to their Order table (not that we are either).
I hope this makes sense, and if anyone has other thoughts or advice we would be interested in hearing them.
Further to this point, what really seems to not make sense is the FIX rules of engagement as enumerated in the Errata documentaiton.
The most simple Example I can think of is an Update.
In Case 1 ClOrdID Applesauce came from System1. on A D message.
Now System2 Wants to update this Order form a logical standpoint. But the ClOrdID was Sytem1’s unique identifier. There’s not going to be a corresponding System2 Ledger entry for that as the orgininating unique identifier. Does System2 Send an Update or a new? How can it send an Update without knowing a Chain to update and no train really exists.
So while the 11 and 37 tags make sense - how does the order matrix work.
Further to this point, what really seems to not make sense is the FIX
rules of engagement as enumerated in the Errata documentaiton.The most simple Example I can think of is an Update.
In Case 1 ClOrdID Applesauce came from System1. on A D message.
Now System2 Wants to update this Order form a logical standpoint. But
the ClOrdID was Sytem1’s unique identifier. There’s not going to be a
corresponding System2 Ledger entry for that as the orgininating unique
identifier. Does System2 Send an Update or a new? How can it send an
Update without knowing a Chain to update and no train really exists.So while the 11 and 37 tags make sense - how does the order matrix work.
I am not able to clearly understand your query but if you are talking about how to Amend/Replace the order
You can use ClOrdId and OrigClOrdId to maintain it ( client will send you these tags if he wants to update the order )
New Order → ClOrdId = 12345 , Qnty = 1000 , symbol = 6501.T
Update Order → OrgClOrdId = 12345 , ClOrdId = 12346 , Qnty =1500 , symbol = 6501.T
– Nand
Maybe you could shed some light on the underlying business model. It seems that both you and your client want to generate orders and send them to the other party. What happens to these orders? Do both of you then execute these orders in one way or another? Can it happen that you create an order and your client subsequently changes order attributes such as price or volume? If yes, what is the rationale behind that?
In general, one party creates an order and assigns an initial ClOrdID to it. This party sends it to a second party for execution. The second party echoes back ClOrdID to allow the first party to match requests to responses. The second party also issues its own ID, namely OrderID and passes that along to the first party. There are different models as to how the first party then identifies an order it wants to change towards the second party. Best practice is that both parties are aware of each others identification and use both IDs when communicating. ClOrdID is rather a message identifier used for chaining whereas OrderID is an entity identifier that does not change during the lifetime of an order.
The FPL Exchanges & ECN Working Group (EEWG) has addressed this issue in its “Recommended Best Practices - Phase 1” document that is available on the EEWG website. It focuses on exchange environments but might be of interest to you too.
Regards,
Hanno.
Hello.
We are designing a solution for a client, and it involves a workflow
that we have not supported before. There will be two-way Order messaging
between us and the client. We will maintain a database with a front end,
and our client will have a database they want synched with ours. Orders
can also be created electronically in their database, and sent to us.When an Order is created in our system, we will send MsgType=D to them.
The other messages involved will be Order Cancel Request (F), Order
Cancel/Replace (G) and ultimately Trades. The client wants all Acks to
use the Execution Report (8). Reject messages will be Order Cancel
Reject (9).I believe all we need to do is correctly chain the orders via the
correct Tags. Every Order will have 2 Order Numbers, one from our system
and one from theirs. Also, we will need to store their internal order
number and they will need to store ours.So this could be an example flow:
- Order created in our system (X):
MsgType(35)=D ClOrdID(11)=Xorder01 …
- Ack back from client (Y):
MsgType(35)=8 ClOrdID(11)=Xorder01 OrderID(37)=Yorder01 …
From this point on, no matter who sends an F or G to who these 2 tags
will always stay the same: ClOrdID(11)=Xorder01 OrderID(37)=Yorder01Am I correct is saying that whoever creates the Order ‘owns’ the 11 tag
from then on? When they create an Order the above flow will be the same,
and we must store whatever they send us in their 11 and use it going
forward for any changes made in our system?Is there any way around this? I know the client is not going to be
thrilled about adding a column to their Order table (not that we
are either).I hope this makes sense, and if anyone has other thoughts or advice we
would be interested in hearing them.
This is exactly the case. The rationale is a very obscure but realistic case where a # of orders will be handled via VRU systems that would need to interface into our Central order system. The same Account might use both.
Thank You!!
SO
create an order and your client subsequently changes order attributes
such as price or volume? YES.
In general, one party creates an order and assigns an initial ClOrdID to
it. This party sends it to a second party for execution. The second
party echoes back ClOrdID to allow the first party to match requests to
responses. The second party also issues its own ID, namely OrderID and
passes that along to the first party. There are different models as to
how the first party then identifies an order it wants to change towards
the second party. Best practice is that both parties are aware of each
others identification and use both IDs when communicating. ClOrdID is
rather a message identifier used for chaining whereas OrderID is an
entity identifier that does not change during the lifetime of an order.The FPL Exchanges & ECN Working Group (EEWG) has addressed this issue in
its “Recommended Best Practices - Phase 1” document that is available on
the EEWG website. It focuses on exchange environments but might be of
interest to you too.Regards, Hanno.
Hello.
We are designing a solution for a client, and it involves a workflow
that we have not supported before. There will be two-way Order
messaging between us and the client. We will maintain a database with
a front end, and our client will have a database they want synched
with ours. Orders can also be created electronically in their
database, and sent to us.When an Order is created in our system, we will send MsgType=D to
them. The other messages involved will be Order Cancel Request (F),
Order Cancel/Replace (G) and ultimately Trades. The client wants all
Acks to use the Execution Report (8). Reject messages will be Order
Cancel Reject (9).I believe all we need to do is correctly chain the orders via the
correct Tags. Every Order will have 2 Order Numbers, one from our
system and one from theirs. Also, we will need to store their internal
order number and they will need to store ours.So this could be an example flow:
- Order created in our system (X):
MsgType(35)=D ClOrdID(11)=Xorder01 …
- Ack back from client (Y):
MsgType(35)=8 ClOrdID(11)=Xorder01 OrderID(37)=Yorder01 …
From this point on, no matter who sends an F or G to who these 2 tags
will always stay the same: ClOrdID(11)=Xorder01 OrderID(37)=Yorder01Am I correct is saying that whoever creates the Order ‘owns’ the 11
tag from then on? When they create an Order the above flow will be the
same, and we must store whatever they send us in their 11 and use it
going forward for any changes made in our system?Is there any way around this? I know the client is not going to be
thrilled about adding a column to their Order table (not that we are
either).I hope this makes sense, and if anyone has other thoughts or advice we
would be interested in hearing them.
I downloaded and read the ECN best practices document. It is very helpful, especially as an overview
of the flow back and forth. And it does mention some of the fields that we have analyzed, such as OrigClOrdID, PossDupFlag, PossResend. I was hoping to see at least some stub examples with the Tags in action. Something along the lines of the Order Modification examples in 4.3.2, but highlighting the Tags used and the contents. I think this would help understand the chaining better where:
Order created in System A, sent to System B
Order Ack from System B to System A
**Now an update occurs in System B for the first time, and needs to be sent to System A. At this point I believe OrderID is from A and ClOrdID is from B (or use SecondaryOrderID instead?).
But I cannot visualize the chain starting on System B’s side, for this first update and send to Sytem A (and the Ack back). System B did not origniate the Order so its first outbound message is going to be an Update (Cancel, etc.) message, it is not going to have its own ‘first’ link in the chain, only A’s first link. I hope this makes sense.
I see a number of other documents in the working group, but they are doc and xls so I cant download them at the office.
Thanks.
This is exactly the case. The rationale is a very obscure but
realistic case where a # of orders will be handled via VRU systems
that would need to interface into our Central order system. The same
Account might use both.Thank You!!
SO
create an order and your client subsequently changes order attributes
such as price or volume? YES.In general, one party creates an order and assigns an initial
ClOrdID to
it. This party sends it to a second party for execution. The second
party echoes back ClOrdID to allow the first party to match
requests to responses. The second party also issues its own ID,
namely OrderID and passes that along to the first party. There are
different models as to how the first party then identifies an
order it wants to change towards the second party. Best practice
is that both parties are aware of each others identification and
use both IDs when communicating. ClOrdID is rather a message
identifier used for chaining whereas OrderID is an entity
identifier that does not change during the lifetime of an order.The FPL Exchanges & ECN Working Group (EEWG) has addressed this issue
in its “Recommended Best Practices - Phase 1” document that is
available on the EEWG website. It focuses on exchange environments but
might be of interest to you too.Regards, Hanno.
Hello.
We are designing a solution for a client, and it involves a workflow
that we have not supported before. There will be two-way Order
messaging between us and the client. We will maintain a database
with a front end, and our client will have a database they want
synched with ours. Orders can also be created electronically in
their database, and sent to us.When an Order is created in our system, we will send MsgType=D to
them. The other messages involved will be Order Cancel Request (F),
Order Cancel/Replace (G) and ultimately Trades. The client wants all
Acks to use the Execution Report (8). Reject messages will be Order
Cancel Reject (9).I believe all we need to do is correctly chain the orders via the
correct Tags. Every Order will have 2 Order Numbers, one from our
system and one from theirs. Also, we will need to store their
internal order number and they will need to store ours.So this could be an example flow:
- Order created in our system (X):
MsgType(35)=D ClOrdID(11)=Xorder01 …
- Ack back from client (Y):
MsgType(35)=8 ClOrdID(11)=Xorder01 OrderID(37)=Yorder01 …
From this point on, no matter who sends an F or G to who these 2
tags will always stay the same: ClOrdID(11)=Xorder01
OrderID(37)=Yorder01Am I correct is saying that whoever creates the Order ‘owns’ the 11
tag from then on? When they create an Order the above flow will be
the same, and we must store whatever they send us in their 11 and
use it going forward for any changes made in our system?Is there any way around this? I know the client is not going to be
thrilled about adding a column to their Order table (not that we are
either).I hope this makes sense, and if anyone has other thoughts or advice
we would be interested in hearing them.