Imported from previous forum
Hi,
I would like to have a way to indicate that a TCR is received but not yet processed. The reason for this is that I have one server process validating the incoming message and another process is doing the specific update.
In FIX 4.4 there is only two different values 0 = Accepted, 1 = Rejected in tag 939 (TrdRptStatus). I would like to have another one saying “Received but not yet processed”.
The interaction would the look like:
- Send TCR (for example amend trade)
- Receive TCR Ack indicating "Received but not yet processed"
3a) Receive a TCR with the amended trade
or
3b) Receive a TCR Ack indicating that the amended was rejected
Can anyone think of another way of solving this problem?
Bernt,
the convention has been to use Accepted followed by Completed for such scenarios. Tag 939 does not have a value for Completed and would need to be extended. There are other examples where such a value makes sense. Please have a look at 750 TradeRequestStatus which has both (and Rejected).
Regards,
Hanno.
Hi,
I would like to have a way to indicate that a TCR is received but not yet processed. The reason for this is that I have one server process validating the incoming message and another process is doing the specific update.
In FIX 4.4 there is only two different values 0 = Accepted, 1 = Rejected in tag 939 (TrdRptStatus). I would like to have another one saying “Received but not yet processed”.
The interaction would the look like:
- Send TCR (for example amend trade)
- Receive TCR Ack indicating “Received but not yet processed”
3a) Receive a TCR with the amended tradeor
3b) Receive a TCR Ack indicating that the amended was rejected
Can anyone think of another way of solving this problem?
To avoid confusion: did not mean to use 750 instead of 939, just an FYI to point to a field where this two step approach is already available. MassActionResponse (1375) is another example where this is missing. I might be able to add your requirement into an upcoming extension proposal. Please contact me offline about this.
Bernt,
the convention has been to use Accepted followed by Completed for such scenarios. Tag 939 does not have a value for Completed and would need to be extended. There are other examples where such a value makes sense. Please have a look at 750 TradeRequestStatus which has both (and Rejected).
Regards,
Hanno.
Bernt,
the convention has been to use Accepted followed by Completed for such scenarios. Tag 939 does not have a value for Completed and would need to be extended. There are other examples where such a value makes sense. Please have a look at 750 TradeRequestStatus which has both (and Rejected).
Regards,
Hanno.Hi,
I would like to have a way to indicate that a TCR is received but not yet processed. The reason for this is that I have one server process validating the incoming message and another process is doing the specific update.
In FIX 4.4 there is only two different values 0 = Accepted, 1 = Rejected in tag 939 (TrdRptStatus). I would like to have another one saying “Received but not yet processed”.
The interaction would the look like:
- Send TCR (for example amend trade)
- Receive TCR Ack indicating “Received but not yet processed”
3a) Receive a TCR with the amended tradeor
3b) Receive a TCR Ack indicating that the amended was rejected
Can anyone think of another way of solving this problem?
Does the convention also allow to use Accepted followed by Rejected if the update fails in a later stage?
Yes, those are the two workflows for a 2 step approach:
Accepted → Completed (success)
Accepted → Rejected (failure)
Accepted then simply means that responsibility has been transferred to the recipient and that a second response message is expected by the submitter.
Sometimes a request cannot even be validated upon entry but the submitter should get something to not think the request was lost. Deferred validation can always lead to a rejection.
Bernt,
the convention has been to use Accepted followed by Completed for such scenarios. Tag 939 does not have a value for Completed and would need to be extended. There are other examples where such a value makes sense. Please have a look at 750 TradeRequestStatus which has both (and Rejected).
Regards,
Hanno.Hi,
I would like to have a way to indicate that a TCR is received but not yet processed. The reason for this is that I have one server process validating the incoming message and another process is doing the specific update.
In FIX 4.4 there is only two different values 0 = Accepted, 1 = Rejected in tag 939 (TrdRptStatus). I would like to have another one saying “Received but not yet processed”.
The interaction would the look like:
- Send TCR (for example amend trade)
- Receive TCR Ack indicating “Received but not yet processed”
3a) Receive a TCR with the amended tradeor
3b) Receive a TCR Ack indicating that the amended was rejected
Can anyone think of another way of solving this problem?
Does the convention also allow to use Accepted followed by Rejected if the update fails in a later stage?
Hanno,
In that case the latter would be fine for now when I need to reject in a later stage, i.e.:
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=0) accepted)
a3) ← TCR Ack (TrdRptStatus=1) rejected)
and the positive case when the update is OK:
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=0) accepted)
b3) ← TCR (notification of the amended trade)
Are these work flows OK for FIX 4.4?
Regards, Bernt
Yes, those are the two workflows for a 2 step approach:
Accepted → Completed (success)
Accepted → Rejected (failure)Accepted then simply means that responsibility has been transferred to the recipient and that a second response message is expected by the submitter.
Sometimes a request cannot even be validated upon entry but the submitter should get something to not think the request was lost. Deferred validation can always lead to a rejection.
Bernt,
the convention has been to use Accepted followed by Completed for such scenarios. Tag 939 does not have a value for Completed and would need to be extended. There are other examples where such a value makes sense. Please have a look at 750 TradeRequestStatus which has both (and Rejected).
Regards,
Hanno.Hi,
I would like to have a way to indicate that a TCR is received but not yet processed. The reason for this is that I have one server process validating the incoming message and another process is doing the specific update.
In FIX 4.4 there is only two different values 0 = Accepted, 1 = Rejected in tag 939 (TrdRptStatus). I would like to have another one saying “Received but not yet processed”.
The interaction would the look like:
- Send TCR (for example amend trade)
- Receive TCR Ack indicating “Received but not yet processed”
3a) Receive a TCR with the amended tradeor
3b) Receive a TCR Ack indicating that the amended was rejected
Can anyone think of another way of solving this problem?
Does the convention also allow to use Accepted followed by Rejected if the update fails in a later stage?
Sometimes user-defined values also work great if both parties agree to use it. For example, you may create a user defined value 100=Pending to resolve your problem.
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=100) pending)
a3) ← TCR Ack (TrdRptStatus=1) rejected)
or
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=100) pending)
b3) ← TCR Ack (TrdRptStatus=0) accepted)
Hope this helps.
Thanks.
Hanno,
In that case the latter would be fine for now when I need to reject in a later stage, i.e.:
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=0) accepted)
a3) ← TCR Ack (TrdRptStatus=1) rejected)and the positive case when the update is OK:
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=0) accepted)
b3) ← TCR (notification of the amended trade)Are these work flows OK for FIX 4.4?
Regards, Bernt
Yes, those are the two workflows for a 2 step approach:
Accepted → Completed (success)
Accepted → Rejected (failure)Accepted then simply means that responsibility has been transferred to the recipient and that a second response message is expected by the submitter.
Sometimes a request cannot even be validated upon entry but the submitter should get something to not think the request was lost. Deferred validation can always lead to a rejection.
Bernt,
the convention has been to use Accepted followed by Completed for such scenarios. Tag 939 does not have a value for Completed and would need to be extended. There are other examples where such a value makes sense. Please have a look at 750 TradeRequestStatus which has both (and Rejected).
Regards,
Hanno.Hi,
I would like to have a way to indicate that a TCR is received but not yet processed. The reason for this is that I have one server process validating the incoming message and another process is doing the specific update.
In FIX 4.4 there is only two different values 0 = Accepted, 1 = Rejected in tag 939 (TrdRptStatus). I would like to have another one saying “Received but not yet processed”.
The interaction would the look like:
- Send TCR (for example amend trade)
- Receive TCR Ack indicating “Received but not yet processed”
3a) Receive a TCR with the amended tradeor
3b) Receive a TCR Ack indicating that the amended was rejected
Can anyone think of another way of solving this problem?
Does the convention also allow to use Accepted followed by Rejected if the update fails in a later stage?
I respectfully disagree with this approach. Technically, tag 939 does not permit user-defined values and with good reason. Status fields are usually key fields in FIX representing a state model and have thus not been opened up for arbitrary values.
However, if such values make sense, they should be added to the list of standard values. Actually, this has already been done and I apologize for not having looked. Here is the current list of valid values for TrdRptStatus (939):
0 - Accepted
1 - Rejected
2 - Cancelled
3 - Accepted with errors
4 - Pending New
5 - Pending Cancel
6 - Pending Replace
This was based on a proposal from the CME with the specific intention to cover the case of a trade report that has been received but not processed in its entirety. It is part of EP107 which has been approved but not yet published as an EP with FIXimate etc.
Bottom line is that “Completed” is not needed as more granular values are already available.
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=6) pending replace)
a3) ← TCR Ack (TrdRptStatus=1) rejected)
or
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=6) pending replace)
b3) ← TCR Ack (TrdRptStatus=0) accepted)
Sometimes user-defined values also work great if both parties agree to use it. For example, you may create a user defined value 100=Pending to resolve your problem.
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=100) pending)
a3) ← TCR Ack (TrdRptStatus=1) rejected)or
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=100) pending)
b3) ← TCR Ack (TrdRptStatus=0) accepted)Hope this helps.
Thanks.
Hanno,
Great. I was not aware of the EP. Thanks for all help.
Regards, Bernt
I respectfully disagree with this approach. Technically, tag 939 does not permit user-defined values and with good reason. Status fields are usually key fields in FIX representing a state model and have thus not been opened up for arbitrary values.
However, if such values make sense, they should be added to the list of standard values. Actually, this has already been done and I apologize for not having looked. Here is the current list of valid values for TrdRptStatus (939):
0 - Accepted
1 - Rejected
2 - Cancelled
3 - Accepted with errors
4 - Pending New
5 - Pending Cancel
6 - Pending ReplaceThis was based on a proposal from the CME with the specific intention to cover the case of a trade report that has been received but not processed in its entirety. It is part of EP107 which has been approved but not yet published as an EP with FIXimate etc.
Bottom line is that “Completed” is not needed as more granular values are already available.
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=6) pending replace)
a3) ← TCR Ack (TrdRptStatus=1) rejected)or
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=6) pending replace)
b3) ← TCR Ack (TrdRptStatus=0) accepted)Sometimes user-defined values also work great if both parties agree to use it. For example, you may create a user defined value 100=Pending to resolve your problem.
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=100) pending)
a3) ← TCR Ack (TrdRptStatus=1) rejected)or
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=100) pending)
b3) ← TCR Ack (TrdRptStatus=0) accepted)Hope this helps.
Thanks.
I had forgotten the link to the GTC link:
See page 9 or search for “939”.
Hanno,
Great. I was not aware of the EP. Thanks for all help.
Regards, Bernt
This is slightly different from what I was suggesting. It makes things more complex if the second message can either be a TCRAck (rejection) or a TCR (success). I had meant to always send two TCRAcks and an additional TCR only for the success case. If the TCRAck is used as a response to the TCR, it seems cleaner to only use TCRAck even if it means one more message in the flow (TCR - TCRAck - TCRAck - TCR).
The final TCR for the success case can then be sent to the submitter as well as to a drop copy subscriber who has no interest in the TCRAck. The submitter, on the other hand, must only process TCRAcks to determine the result of his request.
Hanno,
In that case the latter would be fine for now when I need to reject in a later stage, i.e.:
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=0) accepted)
a3) ← TCR Ack (TrdRptStatus=1) rejected)and the positive case when the update is OK:
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=0) accepted)
b3) ← TCR (notification of the amended trade)Are these work flows OK for FIX 4.4?
Regards, Bernt
Yes, those are the two workflows for a 2 step approach:
Accepted → Completed (success)
Accepted → Rejected (failure)Accepted then simply means that responsibility has been transferred to the recipient and that a second response message is expected by the submitter.
Sometimes a request cannot even be validated upon entry but the submitter should get something to not think the request was lost. Deferred validation can always lead to a rejection.
Hanno,
My latest suggestion was how to solve it now in FIX 4.4 without any changes in the protocol.
For the long run I might prefer the suggestion by Chirag Patel at TradeWeb. It has some advantages:
- The pending state can be optional so that old applications can use the old way of using one TCR Ack message only instead of always sending two messages as in your approach.
- The optional pending state resembles the OrdStatus (pending replace) used for ExecutionReports
Chirag Patels sugggestion was:
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=100) pending)
a3) ← TCR Ack (TrdRptStatus=1) rejected)
or
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=100) pending)
b3) ← TCR Ack (TrdRptStatus=0) accepted)
This is slightly different from what I was suggesting. It makes things more complex if the second message can either be a TCRAck (rejection) or a TCR (success). I had meant to always send two TCRAcks and an additional TCR only for the success case. If the TCRAck is used as a response to the TCR, it seems cleaner to only use TCRAck even if it means one more message in the flow (TCR - TCRAck - TCRAck - TCR).
The final TCR for the success case can then be sent to the submitter as well as to a drop copy subscriber who has no interest in the TCRAck. The submitter, on the other hand, must only process TCRAcks to determine the result of his request.
Hanno,
In that case the latter would be fine for now when I need to reject in a later stage, i.e.:
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=0) accepted)
a3) ← TCR Ack (TrdRptStatus=1) rejected)and the positive case when the update is OK:
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=0) accepted)
b3) ← TCR (notification of the amended trade)Are these work flows OK for FIX 4.4?
Regards, Bernt
Yes, those are the two workflows for a 2 step approach:
Accepted → Completed (success)
Accepted → Rejected (failure)Accepted then simply means that responsibility has been transferred to the recipient and that a second response message is expected by the submitter.
Sometimes a request cannot even be validated upon entry but the submitter should get something to not think the request was lost. Deferred validation can always lead to a rejection.
Understand, but a TrdRptStatus of 100 is less compliant in FIX 4.4 than a value of 6 which is a standard value in a higher FIX version. It is recommended to use standard messages, fields and values from higher versions prior to using user-defined messages, fields and values. If the FIX engine has a problem to pass these messages or fields through to the application, you can prefix the standard message name with “U” and add 20,000 to the standard tag number to create message or field clones.
Should the FIX 4.4 engine check valid values of a field then neither 100 nor 6 will work for tag 939 and you need a UDF 20,939 as a clone of 939 and then you should chose it to be identical to the latest definition which offers the value 6 for Pending Replace.
Hanno,
My latest suggestion was how to solve it now in FIX 4.4 without any changes in the protocol.
For the long run I might prefer the suggestion by Chirag Patel at TradeWeb. It has some advantages:
- The pending state can be optional so that old applications can use the old way of using one TCR Ack message only instead of always sending two messages as in your approach.
- The optional pending state resembles the OrdStatus (pending replace) used for ExecutionReports
Chirag Patels sugggestion was:
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=100) pending)
a3) ← TCR Ack (TrdRptStatus=1) rejected)or
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=100) pending)
b3) ← TCR Ack (TrdRptStatus=0) accepted)This is slightly different from what I was suggesting. It makes things more complex if the second message can either be a TCRAck (rejection) or a TCR (success). I had meant to always send two TCRAcks and an additional TCR only for the success case. If the TCRAck is used as a response to the TCR, it seems cleaner to only use TCRAck even if it means one more message in the flow (TCR - TCRAck - TCRAck - TCR).
The final TCR for the success case can then be sent to the submitter as well as to a drop copy subscriber who has no interest in the TCRAck. The submitter, on the other hand, must only process TCRAcks to determine the result of his request.
Hanno,
In that case the latter would be fine for now when I need to reject in a later stage, i.e.:
a1) → TCR (amend trade)
a2) ← TCR Ack (TrdRptStatus=0) accepted)
a3) ← TCR Ack (TrdRptStatus=1) rejected)and the positive case when the update is OK:
b1) → TCR (amend trade)
b2) ← TCR Ack (TrdRptStatus=0) accepted)
b3) ← TCR (notification of the amended trade)Are these work flows OK for FIX 4.4?
Regards, Bernt
Yes, those are the two workflows for a 2 step approach:
Accepted → Completed (success)
Accepted → Rejected (failure)Accepted then simply means that responsibility has been transferred to the recipient and that a second response message is expected by the submitter.
Sometimes a request cannot even be validated upon entry but the submitter should get something to not think the request was lost. Deferred validation can always lead to a rejection.