Imported from previous forum
Hi all,
I was wondering if there are any recommendations for recovery handling as far as generation of execution reports. Currently, we are basically working on a bridge server with buy-side facing FIX interface and proprietary interface on the other sell-side (execution system). The server does not necessarily have to go down in order to engage in recovery processing with the sell-side system, which can commence recovery messages when it restores its own connections to the systems it talks to down the line.
The problem is that the sell side system sends the latest snapshot of the order state along with all executions only - it does not play back the sequence of order state transitions. That means that due to gaps in order states, we may not be able to precisely determine the original state transitions and therefore generate corresponding execution reports.
Say, we have seen 2 ordinary executions so far and we engage in recovery sequence with the sell-side system. We now see a FILLED order with 5 executions. It also looks like there was an amend during the course of the last 3 executions, but we don’t know when it happened exactly (between execution 3 and 4 or 4 and 5 or maybe before 3).
In your opinion, what execution reports should be sent to the client upon recovery in this particular situation?
It gets hairier if you consider that the client may be waiting for a amend reject, amend accepted or even for penging amend…
Any ideas or suggestions would be greatly appreciated.
[ original email was from Filipp Eritsian - filipp.eritsian@ubs.com ]
I would simply send an ER - Filled. According to the tables (Appendix D in FIX 4.2), Filled is higher priority than Replaced, Partially Filled, New, etc. and buy-side should code their system to that. I would set ClOrdID=OrigClOrdID=last known to me ClOrdID, kind of like with unsolicited amends/cancels.
Cheers
Hi all,
I was wondering if there are any recommendations for recovery handling
as far as generation of execution reports. Currently, we are basically
working on a bridge server with buy-side facing FIX interface and
proprietary interface on the other sell-side (execution system). The
server does not necessarily have to go down in order to engage in
recovery processing with the sell-side system, which can commence
recovery messages when it restores its own connections to the systems it
talks to down the line.The problem is that the sell side system sends the latest snapshot of
the order state along with all executions only - it does not play back
the sequence of order state transitions. That means that due to gaps
in order states, we may not be able to precisely determine the
original state transitions and therefore generate corresponding
execution reports.Say, we have seen 2 ordinary executions so far and we engage in recovery
sequence with the sell-side system. We now see a FILLED order with 5
executions. It also looks like there was an amend during the course of
the last 3 executions, but we don’t know when it happened exactly
(between execution 3 and 4 or 4 and 5 or maybe before 3).In your opinion, what execution reports should be sent to the client
upon recovery in this particular situation?It gets hairier if you consider that the client may be waiting for a
amend reject, amend accepted or even for penging amend…Any ideas or suggestions would be greatly appreciated.
I would simply send an ER - Filled. According to the tables (Appendix D
in FIX 4.2), Filled is higher priority than Replaced, Partially Filled,
New, etc. and buy-side should code their system to that. I would set
ClOrdID=OrigClOrdID=last known to me ClOrdID, kind of like with
unsolicited amends/cancels.Cheers
Hi Filipp,
Don’t I have to generate 3 ER’s? Before recovery kicked in, I have seen and generated ER’s for 2 fills but after recovery finished I detected a total of 5. So would you simply generate 2 Partially Filled ER’s and then a final Filled ER, disregarding any interim trasitions?
What if the order got replaced after the 3rd fill but you never got a chance to get that transition and update the client order ids on your side? In this case we would be generating ER’s with wrong client order ids (disregarding the replaced that did take place)…
What if, after recovery, the order is still live…
Any thoughts?
Thanks,
Andrew
will and
Hi all,
I was wondering if there are any recommendations for recovery handling
as far as generation of execution reports. Currently, we are basically
working on a bridge server with buy-side facing FIX interface and
proprietary interface on the other sell-side (execution system). The
server does not necessarily have to go down in order to engage in
recovery processing with the sell-side system, which can commence
recovery messages when it restores its own connections to the systems
it talks to down the line.The problem is that the sell side system sends the latest snapshot of
the order state along with all executions only - it does not play back
the sequence of order state transitions. That means that due to gaps
in order states, we may not be able to precisely determine the
original state transitions and therefore generate corresponding
execution reports.Say, we have seen 2 ordinary executions so far and we engage in
recovery sequence with the sell-side system. We now see a FILLED order
with 5 executions. It also looks like there was an amend during the
course of the last 3 executions, but we don’t know when it happened
exactly (between execution 3 and 4 or 4 and 5 or maybe before 3).In your opinion, what execution reports should be sent to the client
upon recovery in this particular situation?It gets hairier if you consider that the client may be waiting for a
amend reject, amend accepted or even for penging amend…Any ideas or suggestions would be greatly appreciated.
[ original email was from Jeremy Sutton - jezza.sutton@patsystems.com ]
It does not sound like you have a way to solve this properly (the sell-side system should perhaps be issuing full contextual information on this recovery but it is not).
I believe all you can do is issue any execution reports for the fills and set the order state correctly along with the ClOrdId you hopefully know from the server side recovery.
I guess you might consider setting the PosDup flag as well.
[ original email was from Jeremy Sutton - jezza.sutton@patsystems.com ]
> It does not sound like you have a way to solve this properly (the sell-
side system should perhaps be issuing full contextual information on
this recovery but it is not).I believe all you can do is issue any execution reports for the fills
and set the order state correctly along with the ClOrdId you hopefully
know from the server side recovery.I guess you might consider setting the PosDup flag as well.
Oops. PosResend. Obviously
It does not sound like you have a way to solve this properly (the sell-
side system should perhaps be issuing full contextual information on
this recovery but it is not).I believe all you can do is issue any execution reports for the fills
and set the order state correctly along with the ClOrdId you hopefully
know from the server side recovery.
Regarding the question whether the ExecReports should use the old ClOrdID (before the amend) or the new one (after the amend):
If the Replace has not been confirmed to the buy side by sending back an appropriate ER, you should still use the old ClOrdID:
→ NewOrderSingle(X)
← ER(X, NEW)
← ER(X, Partial Fill)
← ER(X, Partial Fill)
→ OrderCancelReplaceRequest(Y, X)
← ER(X, Partial Fill)
← ER(X, Partial Fill)
← ER(X, Fill)
On the other hand, it may be suprising to get larger fills than specified for this ClOrdID (if the amend increased size), so you may first issue the reply to the amend:
→ NewOrderSingle(X)
← ER(X, NEW)
← ER(X, Partial Fill)
← ER(X, Partial Fill)
→ OrderCancelReplaceRequest(Y, X)
← ER(Y, Replace)
← ER(Y, Partial Fill)
← ER(Y, Partial Fill)
← ER(Y, Fill)
If the accumulated size of all ERs indicates that the backend system did not receive the amend, scenario 1 would fit. Otherwise, scenario 2.
Still have to work out how the order state should be…
I guess you might consider setting the PosDup flag as well.
Your are most probably mean PossResend=Y here.
Cheers, Jörg