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

[Brian E. <azz...@ya...>]

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 ===