Imported from previous forum
[ original email was from Jeffrey Croft - jeff.croft@plusmarketsgroup.com ]
Lets say a FIX gateway validates a session (local config for user/port held on gateway) but for some reason the static data that supports that client is missing from the DB. An OrderCancelRequest comes through and needs to be rejected by the Gateway as it cannot route the Cancel Request to the matching engine as its lookup for that client fails. What should be returned in tag 39 OrdStatus of the OrderCancelReject?
From specifications: “If CxlRejReason = “Unknown Order”, specify Rejected.”
Lets say a FIX gateway validates a session (local config for user/port held on gateway) but for some reason the static data that supports that client is missing from the DB. An OrderCancelRequest comes through and needs to be rejected by the Gateway as it cannot route the Cancel Request to the matching engine as its lookup for that client fails. What should be returned in tag 39 OrdStatus of the OrderCancelReject?
[ original email was from Jeffrey Croft - jeff.croft@plusmarketsgroup.com ]
But the order ref is good its just that we cannot identify the Client. If you send back ‘Rejected’ as the current order status then the client would think that a valid order they had sitting on the orderbook is now rejected.
From specifications: “If CxlRejReason = “Unknown Order”, specify Rejected.”
Lets say a FIX gateway validates a session (local config for user/port held on gateway) but for some reason the static data that supports that client is missing from the DB. An OrderCancelRequest comes through and needs to be rejected by the Gateway as it cannot route the Cancel Request to the matching engine as its lookup for that client fails. What should be returned in tag 39 OrdStatus of the OrderCancelReject?
Couldn’t it be taken for “unknown order for the specified client”?
But the order ref is good its just that we cannot identify the Client. If you send back ‘Rejected’ as the current order status then the client would think that a valid order they had sitting on the orderbook is now rejected.
From specifications: “If CxlRejReason = “Unknown Order”, specify Rejected.”
Lets say a FIX gateway validates a session (local config for user/port held on gateway) but for some reason the static data that supports that client is missing from the DB. An OrderCancelRequest comes through and needs to be rejected by the Gateway as it cannot route the Cancel Request to the matching engine as its lookup for that client fails. What should be returned in tag 39 OrdStatus of the OrderCancelReject?
Your scenario sounds more like a severe error that goes way beyond problems with a single order and should maybe also cause the session to be terminated with an appropriate value in SessionStatus (1409).
An order status of “Rejected” also applies to other situations, not only the loss of client data or loss of connectivity to the target system. The user may also not be authorized to access the order and its attributes and you may not want to reveal its current status. OrdStatus is a required field and hence you have to give it a value. OrdRejReason is a good place to explain the nature of the rejection. The way you describe it, you cannot determine whether the order does actually exist or not and assuming “unknown order” may be your best option. In any case you do do have the actual order status.
An order that has been accepted without a pending status cannot be rejected afterwards. The user can safely assume that this did not happen but that there is a different reason for the OrdStatus being set to “Rejected”. He may have to seek access to his order (if it is his) out of band in such a case (e.g. phone call) because his request to cancel was rejected and the order is still active in the market. You could argue that OrdStatus should not be a required field in such cases but that is a different discussion.
Regards,
Hanno.
But the order ref is good its just that we cannot identify the Client. If you send back ‘Rejected’ as the current order status then the client would think that a valid order they had sitting on the orderbook is now rejected.
From specifications: “If CxlRejReason = “Unknown Order”, specify Rejected.”
Lets say a FIX gateway validates a session (local config for user/port held on gateway) but for some reason the static data that supports that client is missing from the DB. An OrderCancelRequest comes through and needs to be rejected by the Gateway as it cannot route the Cancel Request to the matching engine as its lookup for that client fails. What should be returned in tag 39 OrdStatus of the OrderCancelReject?
[ original email was from Jeffrey Croft - jeff.croft@plusmarketsgroup.com ]
I think the best action is indeed to drop the connection as from that point on the session is going to be problematic. Thanks for the reply.
Your scenario sounds more like a severe error that goes way beyond problems with a single order and should maybe also cause the session to be terminated with an appropriate value in SessionStatus (1409).
An order status of “Rejected” also applies to other situations, not only the loss of client data or loss of connectivity to the target system. The user may also not be authorized to access the order and its attributes and you may not want to reveal its current status. OrdStatus is a required field and hence you have to give it a value. OrdRejReason is a good place to explain the nature of the rejection. The way you describe it, you cannot determine whether the order does actually exist or not and assuming “unknown order” may be your best option. In any case you do do have the actual order status.
An order that has been accepted without a pending status cannot be rejected afterwards. The user can safely assume that this did not happen but that there is a different reason for the OrdStatus being set to “Rejected”. He may have to seek access to his order (if it is his) out of band in such a case (e.g. phone call) because his request to cancel was rejected and the order is still active in the market. You could argue that OrdStatus should not be a required field in such cases but that is a different discussion.
Regards,
Hanno.But the order ref is good its just that we cannot identify the Client. If you send back ‘Rejected’ as the current order status then the client would think that a valid order they had sitting on the orderbook is now rejected.
From specifications: “If CxlRejReason = “Unknown Order”, specify Rejected.”
Lets say a FIX gateway validates a session (local config for user/port held on gateway) but for some reason the static data that supports that client is missing from the DB. An OrderCancelRequest comes through and needs to be rejected by the Gateway as it cannot route the Cancel Request to the matching engine as its lookup for that client fails. What should be returned in tag 39 OrdStatus of the OrderCancelReject?