Fill Or Kill Execution Report State Changes

, ,
1

Imported from previous forum

2

Hi,

In FIX v 4.3, it is mentioned that an OrderStatus in an ExecutionReport can go from state New to Rejected (Pg. 13 of Vol 4, FIX 4.3). It does not mention however whether this is applicable for only specific order types.

I am interested in knowing whether this can be applied for Fill Or Kill Orders as well. State transition charts provided in the same document lists Fill Or Kill as going to either directly Rejected or New -> Cancelled. But the note on Execution Reports seem to suggest that New -> Rejected is also possible (?),

Thanks,

  • Raj.
3

The use case for New->Rejected is a rare one to begin with. The first scenario of the Order State Change Matrices shows it (1 - Vanilla - Filled Order). The case involves two independent validations (sales and trader/exchange). The sales guy accepts the order but the trader/exchange rejects it. That could basically happen for any order type, i.e. also FOK, for example if the exchange does not support it but the sales guy does.
I do not think it makes sense when there is only a single point of validation to use New->Rejected, it should then be Pending New->Rejected. The latter can make sense for a technical acceptance where it takes a while to conduct the functional validation, e.g. in the context of floor trading. It just means that the recipient has taken over responsibility for the transaction.
So the answer is “it depends…” as you need to know the counterparties you are dealing with. Normally, I would expect either Reject (rejection) or New->Cancelled (not filled) or New->Filled (fully filled) for an FOK order. Please note that Volume 7 of FIX 5 SP1 (page 192) shows state changes when using FIX for high performance. In such a case you only get a single ExecutionReport with the final state of the order, i.e. you get Reject or Cancelled or Filled for an FOK order.
Regards,
Hanno.

Hi,

In FIX v 4.3, it is mentioned that an OrderStatus in an ExecutionReport can go from state New to Rejected (Pg. 13 of Vol 4, FIX 4.3). It does not mention however whether this is applicable for only specific order types.

I am interested in knowing whether this can be applied for Fill Or Kill Orders as well. State transition charts provided in the same document lists Fill Or Kill as going to either directly Rejected or New → Cancelled. But the note on Execution Reports seem to suggest that New → Rejected is also possible (?),

Thanks,

  • Raj.
4

I would like to agree with Hanno that it is very rare for this to happen, especially in DMA flow. I have certainly seen it happen on CARE/Worked Order in the past.

It can also happen in DMA, for example, where the first execution report is handled by a third party and not the exchange (has been used as a cheeky way to mask actual latency by some vendors in the past). For example on certain staging platforms or synthetic order managers.

For DMA in one of my previous places we built some logic round the basis that if an order is in a “new” state and for whatever reason a reject follows, this gets converted into a “cancel” back to the originator to make sure that the originator did not have to deal with these scenarios. For CARE/Worked Orders we held the reject and let the desk have the option to manually cancel, or work the order differently.

In my eyes though, every version of FIX should be built to deal with the state changes as in Volume 7 of FIX 5 SP1, that way there can be no confusion.

My pennies worth :slight_smile:

The use case for New->Rejected is a rare one to begin with. The first scenario of the Order State Change Matrices shows it (1 - Vanilla - Filled Order). The case involves two independent validations (sales and trader/exchange). The sales guy accepts the order but the trader/exchange rejects it. That could basically happen for any order type, i.e. also FOK, for example if the exchange does not support it but the sales guy does.
I do not think it makes sense when there is only a single point of validation to use New->Rejected, it should then be Pending New->Rejected. The latter can make sense for a technical acceptance where it takes a while to conduct the functional validation, e.g. in the context of floor trading. It just means that the recipient has taken over responsibility for the transaction.
So the answer is “it depends…” as you need to know the counterparties you are dealing with. Normally, I would expect either Reject (rejection) or New->Cancelled (not filled) or New->Filled (fully filled) for an FOK order. Please note that Volume 7 of FIX 5 SP1 (page 192) shows state changes when using FIX for high performance. In such a case you only get a single ExecutionReport with the final state of the order, i.e. you get Reject or Cancelled or Filled for an FOK order.
Regards,
Hanno.

Hi,

In FIX v 4.3, it is mentioned that an OrderStatus in an ExecutionReport can go from state New to Rejected (Pg. 13 of Vol 4, FIX 4.3). It does not mention however whether this is applicable for only specific order types.

I am interested in knowing whether this can be applied for Fill Or Kill Orders as well. State transition charts provided in the same document lists Fill Or Kill as going to either directly Rejected or New → Cancelled. But the note on Execution Reports seem to suggest that New → Rejected is also possible (?),

Thanks,

  • Raj.
5

Hi,

One fine example is the order is placed before market starts and exchange gives a rejection message saying “Markets not open” with an exchange error code.

6

Hi,

One fine example is the order is placed before market starts and exchange gives a rejection message saying “Markets not open” with an exchange error code.