Imported from previous forum
I have recently been brought to the attention of the following sentence in the FIX specs (at least since version 4.0) against the Pending New OrdStatus under the Execution Report section:
“An execution message with this status will only be sent in response to a Status Request message.”
Is this really true? Can the sell-side not send out a Pending New ER directly in response to a New Order? Does this mean that line 2 in the following scenario doesn’t hold good:
- –> buy-side sends New Order – Single
- <-- sell-side sends Execution Report – Pending New (optional)
- <-- sell-side sends Execution Report – NEW
Or is it just an oversight in the specs. As sell-side, we have been using the Pending New ER in response to New Orders on certain flows, but now wonder if this is ‘against’ the FIX specifications.
Regards and Thanks in advance
Vinay Gaur
UBS
[ original email was from KEVIN YOUNG - KYOUNG@YOUNGFE.COM ]
An order is understood to be ‘Pending New’ if the initiator didn’t receive an Ack yet. While I see the logic and benefit in your Pending New ExecutionReport, I don’t think it was the FIX groups original intent for workflow or an oversight. I wouldn’t say it is ‘against’ the FIX spec, merely your interpretation to improve workflow.
I have recently been brought to the attention of the following sentence
in the FIX specs (at least since version 4.0) against the Pending New
OrdStatus under the Execution Report section: “An execution message with
this status will only be sent in response to a Status Request message.”Is this really true? Can the sell-side not send out a Pending New ER
directly in response to a New Order? Does this mean that line 2 in the
following scenario doesn’t hold good:
- → buy-side sends New Order – Single
- ← sell-side sends Execution Report – Pending New (optional)
- ← sell-side sends Execution Report – NEW
Or is it just an oversight in the specs. As sell-side, we have been
using the Pending New ER in response to New Orders on certain flows, but
now wonder if this is ‘against’ the FIX specifications.Regards and Thanks in advance Vinay Gaur UBS
I’d say it’s still against “the letter of the law”, the spec is clear – “only be sent in response to a Status Request”. Hence this should not be the default behaviour probably. Some parties may not be expecting this status if they never send Status Request. However FIX is not a law so it’s probably fine if both counter-parties agree to do so. In fact some clients require Pending New ER as a recipience confirmation while order is not yet accepted “officially”. Optional support depending on the client preferences is probably most sensible.
An order is understood to be ‘Pending New’ if the initiator didn’t
receive an Ack yet. While I see the logic and benefit in your Pending
New ExecutionReport, I don’t think it was the FIX groups original intent
for workflow or an oversight. I wouldn’t say it is ‘against’ the FIX
spec, merely your interpretation to improve workflow.I have recently been brought to the attention of the following
sentence in the FIX specs (at least since version 4.0) against the
Pending New OrdStatus under the Execution Report section: “An
execution message with this status will only be sent in response to a
Status Request message.”Is this really true? Can the sell-side not send out a Pending New ER
directly in response to a New Order? Does this mean that line 2 in the
following scenario doesn’t hold good:
- → buy-side sends New Order – Single
- ← sell-side sends Execution Report – Pending New (optional)
- ← sell-side sends Execution Report – NEW
Or is it just an oversight in the specs. As sell-side, we have been
using the Pending New ER in response to New Orders on certain flows,
but now wonder if this is ‘against’ the FIX specifications.Regards and Thanks in advance Vinay Gaur UBS
[ original email was from John Prewett - jprewett@lavatrading.com ]
It certainly seems to be against the letter of the law in FIX.4.0.
That said, common sense rules still apply:
- Be 100% compliant in what you send.
- Be very flexible in what you are prepared to receive.
There are many cases where FIX.4.0 is ambiguous yet the ambiguity is resolved by later FIX versions. Under those circumstances, many FIX users take the subsequent resolution of the ambiguity as the preferred behavior for FIX.4.0, despite the fact that the official specification retains the ambiguity. I think this is a perfectly good approach.
Unfortunately, this specific case doesn’t appear to be ambiguous. Nonetheless, flexible FIX.4.0 applications should probably be prepared to receive pending new ExecReports when ExecTransType=New as these are legal in subsequent FIX versions.
On a personal preference, I have never favored sending any “pending” messages. They add latency and reduce throughput in high volume situations. They contain very little information that can be used by a business application. The only major use for them is for latency tracking - yet they may well be the cause of the excessive latency.
JohnP
[ original email was from Kevin English - kevin.english@citigroup.com ]
In defence of the ‘pending’ messages 
I believe that the ‘pending’ messages serve a couple of very useful purposes.
They can be useful from a :
- business perspective when defining ownership in the rules of
engagement document; - systems perspective in confirming order delivery to
sell-side order management system in a timely fashion;
Obviously, these messages introduce latency and eat-up valuable network bandwidth and this may not be acceptable when say the sell-side is an
exchange for example.
As John has pointed out already the common sense approach is best:
- Be 100% compliant in what you send.
- Be very flexible in what you are prepared to receive.
cheers
Kevin
It certainly seems to be against the letter of the law in FIX.4.0.
That said, common sense rules still apply:
- Be 100% compliant in what you send.
- Be very flexible in what you are prepared to receive.
There are many cases where FIX.4.0 is ambiguous yet the ambiguity is
resolved by later FIX versions. Under those circumstances, many FIX
users take the subsequent resolution of the ambiguity as the preferred
behavior for FIX.4.0, despite the fact that the official specification
retains the ambiguity. I think this is a perfectly good approach.Unfortunately, this specific case doesn’t appear to be ambiguous.
Nonetheless, flexible FIX.4.0 applications should probably be prepared
to receive pending new ExecReports when ExecTransType=New as these are
legal in subsequent FIX versions.On a personal preference, I have never favored sending any “pending”
messages. They add latency and reduce throughput in high volume
situations. They contain very little information that can be used by a
business application. The only major use for them is for latency
tracking - yet they may well be the cause of the excessive latency.JohnP
In defence of the ‘pending’ messages
They can be useful from a :
- business perspective when defining ownership in the rules of
engagement document;- systems perspective in confirming order delivery to sell-side order
management system in a timely fashion;
IMHO, these messages are esp. useful for FIX gateways connecting to proprietary backend systems. Here e.g. the Pending New message completes the work flow: Message sent to backend system, but no acknowledge received.
Obviously, these messages introduce latency and eat-up valuable network
bandwidth and this may not be acceptable when say the sell-side is an
exchange for example.
True, but this should be a reason to disallow them in the spec. I would find it more orthogonal if the spec would allow them to be optionally be sent.
Cheers, Jörg
I have found them to be useful in that the originator can be assured that the message has arrived at its destination.
Byron
Net2s
It certainly seems to be against the letter of the law in FIX.4.0.
That said, common sense rules still apply:
- Be 100% compliant in what you send.
- Be very flexible in what you are prepared to receive.
There are many cases where FIX.4.0 is ambiguous yet the ambiguity is
resolved by later FIX versions. Under those circumstances, many FIX
users take the subsequent resolution of the ambiguity as the preferred
behavior for FIX.4.0, despite the fact that the official specification
retains the ambiguity. I think this is a perfectly good approach.Unfortunately, this specific case doesn’t appear to be ambiguous.
Nonetheless, flexible FIX.4.0 applications should probably be prepared
to receive pending new ExecReports when ExecTransType=New as these are
legal in subsequent FIX versions.On a personal preference, I have never favored sending any “pending”
messages. They add latency and reduce throughput in high volume
situations. They contain very little information that can be used by a
business application. The only major use for them is for latency
tracking - yet they may well be the cause of the excessive latency.JohnP
[ original email was from Jeremy Sutton - jezza.sutton@patsystems.com ]
> I have found them to be useful in that the originator can be assured
that the message has arrived at its destination.
I would agree with that. Although our FIX sell-side took the law to heart and does not send these out, even though we essentially are a middle-man and pass them on. I would like these to be considered optional at some point in the future, in which case I might send them as a confirmation I got and am processing your order on my servers somewhere. This makes New Order Single behave like Cancel and Cancel/Replace.