RE: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[Steve B. <st...@te...>]

Hi Brian,

Interesting. I see the sentence that says Pending New should only
be sent for a Status Request message. However, I also see several
scenarios in the 4.4 specification where Pending New is sent in
response to orders (e.g. Acknowledgement of a Cross Order, Volume 4,
pg. 93).

I don't recall that we ever had a client FIX engine that had a
problem with the Pending New response to an order.

Like you said, it's a judgment call involving various tradeoffs.
I would have guessed that it's more likely that FIX engines would
be able to process a Pending New response to an order (since popular
ECNs like Island implement this behavior) than process a nonstandard
enumerated value for an existing tag. The latter would require engine 
code modifications in some of the home-brew implementations I've
seen (due to inflexible validation code or hard-coded enumeration
representations). A user-defined tag would be another option, but 
it may require the client to make application-level changes and I'd
still have to select an OrdStatus for the Execution Report anyway.

Isn't FIX fun? ;-)

Regards,

Steve

> -----Original Message-----
> From: Brian Erst [mailto:azz...@ya...]
> Sent: Friday, June 03, 2005 10:50 AM
> To: Steve Bate; qui...@li...; quickfix-
> dev...@li...
> Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send
> response to a client
> 
> Steve -
> 
> I'd be happy to move this to one or the other list. The original
> question went to both. I'm not currently subscribed to developers, so
> users probably makes more sense.
> 
> In regards the use of "Pending New" vs. "New", I think I was a little
> unclear in a previous message. According to the FIX specification,
> "Pending New" is only to be used in response to a Status Request. Many
> people in the industry have extended its use to mean "at the router",
> but technically it's a violation of the protocol.
> 
> We thought it better to add field values (that could be ignored if
> needed) rather than redefine existing values. Considering widespread
> industry use, we probably would have been safe either way, but we
> didn't want to cause problems with existing FIX engines. We've
> generally found it is easier to extend an engine to accept new field
> values than to change how it handles existing ones.
> 
> One could make the argument that we should have used "New" to indicate
> acceptance by the exchange and an extended value to indicate acceptance
> by our system. We felt that due to a number of issues (mainly having to
> do with the fact that some orders would never end up at an exchange) it
> made more sense the other way, but that was purely a judgment call. I
> can easily see someone deciding the reverse is better.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- Steve Bate <st...@te...> wrote:
> 
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > (Should we move this discussion to either the user or the developer
> > list
> > rather than both?)
> >
> > At one place I've worked they used Pending New to acknowledge
> > reception of
> > the order at the order router. The order was then sent to an exchange
> > and the exchange sent back a New or Rejected status after it received
> > the order. That report and subsequent ones were forwarded back to the
> > client. A few exchanges also sent a Pending New but we didn't send
> > those back to the client. The customers of that system were satisfied
> >
> > with that approach and it required no custom status codes.
> >
> > I'm a little confused. Is the custom status code being used to
> > communicate that the order was /sent/ to the exchange rather than
> > as an acknowledgement that the exchange received the order?
> >
> > Regards,
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: qui...@li...
> > [mailto:quickfix-users-
> > > ad...@li...] On Behalf Of James C. Downs
> > > Sent: Friday, June 03, 2005 9:58 AM
> > > To: azz...@ya...; 'rohan joel pais'; quickfix-
> > > dev...@li...;
> > qui...@li...
> > > Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send
> > > response to a client
> > >
> > > QuickFIX Documentation:
> > > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > > QuickFIX Support: http://www.quickfixengine.org/services.html
> > >
> > > Brian,
> > > This is a great example of how all the differences in business
> > > requirements
> > > from implementation to implementation cannot be completely covered
> > by a
> > > standard protocol. This is also a good real world example for those
> > who
> > > are
> > > new to FIX struggling with the map between the protocol and
> > business needs
> > > and how that gap is bridged.
> > >
> > > Would you mind commenting on the general reaction of a new
> > counterparty to
> > > your system when they are presented with custom field values (at
> > the
> > > application level)? Is it an education process as to the value the
> > custom
> > > values bring to the implementation?
> > >
> > > Thanks,
> > > Jim
> > >
> > > -----Original Message-----
> > > From: Brian Erst [mailto:azz...@ya...]
> > > Sent: Friday, June 03, 2005 9:39 AM
> > > To: James C. Downs; azz...@ya...; 'rohan joel
> > pais';
> > > qui...@li...;
> > > qui...@li...
> > > Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send
> > > response
> > > to a client
> > >
> > > James -
> > >
> > > The problem occurs when you have a fairly sophisticated order
> > management
> > > system that acts as more than just a proxy pass-through to an
> > exchange.
> > > Here's an example of an issue that (so far) has best been resolved
> > through
> > > additional OrdStatus values.
> > >
> > > The system I work on has connections to 12 different futures
> > exchanges.
> > > We attempt to deliver a consistent interface for all these
> > exchanges, even
> > > when any particular underlying exchange may not support the
> > superset of
> > > functionality across the many exchanges. For instance, not all of
> > the
> > > exchange systems support stop orders (even though the use of such
> > orders
> > > is
> > > widespread throughout the industry). For those exchanges that do
> > not
> > > support
> > > stop orders, we have created a process that simulates stop order
> > > processing
> > > within our order management system.
> > > Essentially, we hold the orders, listen to the price feed and
> > submit the
> > > orders once the trigger price has been touched.
> > >
> > > For these orders, they may NEVER reach the exchange system (price
> > is not
> > > matched). We need a consistent way of telling our users when orders
> > have
> > > been accepted into our system for management, when (if) they have
> > been
> > > diverted to our internal stop processing ssytem, when the orders
> > get
> > > elected
> > > into the market and when the order actually reaches the market.
> > >
> > > The simplest way to handle this (by far) was to add a few
> > additional
> > > OrdStatus/ExecType values. We define "NEW" as being accepted by OUR
> > > application and add three new values ('l' for locally working
> > stops, 'e'
> > > for
> > > stop order election and 'x' for at the exchange).
> > >
> > > In this way, our clients know where an order is at all times. Just
> > as
> > > importantly, our helpdesk knows where that order is as well. If the
> > client
> > > experiences a communications failure and needs to work their
> > orders, they
> > > should still have some idea as to what their current market risk is
> > while
> > > talking with our helpdesk to manage their open orders.
> > >
> > > - Brian Erst
> > > Thynk Software, Inc.
> > >
> > > --- "James C. Downs" <jc...@co...> wrote:
> > >
> > > > QuickFIX Documentation:
> > > > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > > > QuickFIX FAQ:
> > > > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > > > QuickFIX Support: http://www.quickfixengine.org/services.html
> > > >
> > > > Brian,
> > > > I'm curious why in your case the OrdStatus = "NEW" was not
> > sufficient
> > > > to indicate that the order was accepted by the exchange and in
> > the
> > > > market? What exchange/venue was most problematic for you in this
> > > > regard?
> > > >
> > > > Thanks,
> > > > Jim
> > > >
> > > > -----Original Message-----
> > > > From: qui...@li...
> > > > [mailto:qui...@li...] On
> > Behalf Of
> > > > Brian Erst
> > > > Sent: Friday, June 03, 2005 7:45 AM
> > > > To: rohan joel pais; qui...@li...;
> > > > qui...@li...
> > > > Subject: [Quickfix-developers] Re: [Quickfix-users] how to send
> > > > response to a client
> > > >
> > > > QuickFIX Documentation:
> > > > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > > > QuickFIX FAQ:
> > > > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > > > QuickFIX Support: http://www.quickfixengine.org/services.html
> > > >
> > > > I have a very similar application and I eventually decided that
> > the
> > > > "better"
> > > > way was to add additional ExecType/OrdStatus values and use those
> > to
> > > > differentiate between "my application has received the order"
> > > > and "the exchange has received the order".
> > > >
> > > > In my particular case, I use Pending New (OrdStatus='0') to
> > indicate
> > > > that my app received and databased the order. I created a new
> > > > OrdStatus ('x'
> > > > for at
> > > > the eXchange) to indicate that the order had been received by the
> > > > exchange.
> > > >
> > > > FIX hasn't fully come to terms with third-party order management
> > > > systems acting as a bridge between clients and exchanges.
> > Hopefully
> > > > they will start looking at that (if they haven't already) as most
> > of
> > > > the ISVs out there are now adding some sort of FIX interface to
> > their
> >
> === message truncated ===