quickfix-users

[Quickfix-users] how to send response to a client

[rohan j. p. <roh...@re...>]

 =A0=0AHi all,=0A       I need some help in developing a new project. It is=
 like this -  My application will act like a passer, which recieves fix mes=
sages from the client and then converts it into another format and sends it=
 to the exchange.=0ABut my problem here is i want to tell the client that i=
 have recieved his order, without sending him the execution report. so i am=
 asking whether i can build my own response message and send it to the clie=
nt.=0A=0Awith regards=0Arohan pais=0A

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

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

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
order management systems.

- Brian Erst
Thynk Software, Inc.

--- rohan joel pais <roh...@re...> wrote:

>   
> Hi all,
>        I need some help in developing a new project. It is like this
> -  My application will act like a passer, which recieves fix messages
> from the client and then converts it into another format and sends it
> to the exchange.
> But my problem here is i want to tell the client that i have recieved
> his order, without sending him the execution report. so i am asking
> whether i can build my own response message and send it to the
> client.
> 
> with regards
> rohan pais
> 

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

[James C. D. <jc...@co...>]

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 order management systems.

- Brian Erst
Thynk Software, Inc.

--- rohan joel pais <roh...@re...> wrote:

>   
> Hi all,
>        I need some help in developing a new project. It is like this
> -  My application will act like a passer, which recieves fix messages 
> from the client and then converts it into another format and sends it 
> to the exchange.
> But my problem here is i want to tell the client that i have recieved 
> his order, without sending him the execution report. so i am asking 
> whether i can build my own response message and send it to the client.
> 
> with regards
> rohan pais
> 



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

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

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

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 order management
> systems.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- rohan joel pais <roh...@re...> wrote:
> 
> >   
> > Hi all,
> >        I need some help in developing a new project. It is like
> this
> > -  My application will act like a passer, which recieves fix
> messages 
> > from the client and then converts it into another format and sends
> it 
> > to the exchange.
> > But my problem here is i want to tell the client that i have
> recieved 
> > his order, without sending him the execution report. so i am asking
> 
> > whether i can build my own response message and send it to the
> client.
> > 
> > with regards
> > rohan pais
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

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

[James C. D. <jc...@co...>]

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 
> order management systems.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- rohan joel pais <roh...@re...> wrote:
> 
> >   
> > Hi all,
> >        I need some help in developing a new project. It is like
> this
> > -  My application will act like a passer, which recieves fix
> messages
> > from the client and then converts it into another format and sends
> it
> > to the exchange.
> > But my problem here is i want to tell the client that i have
> recieved
> > his order, without sending him the execution report. so i am asking
> 
> > whether i can build my own response message and send it to the
> client.
> > 
> > with regards
> > rohan pais
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own 
> Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own 
> Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

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

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

(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
> > order management systems.
> >
> > - Brian Erst
> > Thynk Software, Inc.
> >
> > --- rohan joel pais <roh...@re...> wrote:
> >
> > >
> > > Hi all,
> > >        I need some help in developing a new project. It is like
> > this
> > > -  My application will act like a passer, which recieves fix
> > messages
> > > from the client and then converts it into another format and sends
> > it
> > > to the exchange.
> > > But my problem here is i want to tell the client that i have
> > recieved
> > > his order, without sending him the execution report. so i am asking
> >
> > > whether i can build my own response message and send it to the
> > client.
> > >
> > > with regards
> > > rohan pais
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your own
> > Applications - visit
> > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your own
> > Applications - visit
> > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> > _______________________________________________
> > Quickfix-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-users
> >
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users

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

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

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

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

Steve -

The rules for "Pending New" have certainly been relaxed since 4.0, but
they persist in leaving in that sentence about Status Requests. Given
that, we went with the new values.

I agree that a bunch of people do use "Pending New" - enough so that
it's probably a de-facto industry standard. It's a little too late to
make the change now, but I'd probably use it on a different project.

I'd still have problems with a couple of other issues (our stop
processing, for one).

FIX is at best a jumping off point. I don't think it'll ever get to the
point that no one needs to tweak it anymore.

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

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

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

James -

We have two groups of users connecting to our applications. 

The first set are clients who are new to FIX. Their biggest issues tend
to be the session management parts and just getting their minds wrapped
around the whole FIX process. For these users, a couple of additional
field values isn't an issue - development is new and the values have no
intrinsic "meaning" to them anyway. They generally write to the FIX
documents that we provide.

The second set are clients that have pre-existing FIX implementations.
Many clients like to use FIX as a "standard" way to communicate to
several different ISV or FCM systems - a way to mitigate risk and
vendor lock-in. These users will sometimes grumble about yet another
instance of non-standard behavior, but pretty much EVERY ISV/FCM has to
deviate from the standard in some way. The addition of a few new field
values is actually pretty easy compared with different FIX versions
(4.2 and 4.3 being the most popular, but a few 4.0 and 4.4 versions are
out in the wild) and non-standard session management. 

Aside from the additional field values, we've only made a few other
extensions to the protocol: 

1. The addition of tag 789 (NextExpectedMsgSeqNum) on logout messages
(a 4.4 field backported to our 4.3 application). Nearly every customer
loves this addition.

2. Co-opting the SecurityExchange tag (207) to use as an exchange
specifier (e.g., which exchange is this order for?). The only other
choice was to mess around with the Symbol tag, and we thought this
implementation was cleaner.

3. Adding some additional exchange-specific OrdTypes - there are some
pretty funky order types out there and FIX doesn't have values for all
of them.

4. We also drop the ClOrdId on some of the ExecutionReports (due to
limitations within our own legacy app), but this is not unusual
behavior out in the real world.

We do a number of things to mitigate our changes to the specification.
First, we use a very small subset of available FIX fields on orders and
execution reports (typically for us, any order can be submitted using
only 12 tags). Second, we provide additional QuickFIX documentation and
a custom FIX43.XML file to encourage QuickFIX usage - it's vastly
simpler to use than coding all the session management stuff yourself.
(I know - I've written FIX engines into four different exchanges.)
There a couple of things I'd change about QuickFIX [which I've posted
about in the past], but it's vastly superior to anything else out
there.

I think pretty much everyone in the industry uses quotes when they
speak of the FIX "standard". It's a nice starting point, but no one in
the futures industry makes any attempt to stick closely to every
detail. In many cases, it's been impossible (until 4.4, many futures
industry-specific data simply did not have tags). In others, it's
inertia or hubris (the CME is notorious for its "improvements" to the
FIX specification - while simultaneously sticking to the 4.2 release
that doesn't support futures). I think the situation is getting better
now that the exchanges are much more active in the specification - but
even that is a mixed bag, as they continue to push the spec to handle
exchange needs while ignoring the needs of ISVs and FCMs.

Of course, wait until you see the "implicit tagging" specification
that's being worked on - the QuickFIX team will have PLENTY of work in
the future! >;-)

- 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,
> 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 
> > order management systems.
> > 
> > - Brian Erst
> > Thynk Software, Inc.
> > 
> > --- rohan joel pais <roh...@re...> wrote:
> > 
> > >   
> > > Hi all,
> > >        I need some help in developing a new project. It is like
> > this
> > > -  My application will act like a passer, which recieves fix
> > messages
> > > from the client and then converts it into another format and
> sends
> > it
> > > to the exchange.
> > > But my problem here is i want to tell the client that i have
> > recieved
> > > his order, without sending him the execution report. so i am
> asking
> > 
> > > whether i can build my own response message and send it to the
> > client.
> > > 
> > > with regards
> > > rohan pais
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your
> own 
> > Applications - visit
> > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> 
=== message truncated ===

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

[Caleb E. <cal...@gm...>]

On 6/3/05, James C. Downs <jc...@co...> wrote:

> I'm curious why in your case the OrdStatus =3D "NEW" was not sufficient t=
o
> indicate that the order was accepted by the exchange and in the market? W=
hat
> exchange/venue was most problematic for you in this regard?

I think the answer depends on how fine-grained you want to make the
information you pass back to clients of a system.  Especially if
messages take more than one hop before they go out the door.  Consider
for example this system:

Client app -> FIX router -> ECNs

If the FIX router were purely a message-passing application, it would
just rely on the ECNs to generate all of the execution reports and
wouldn't generate any of its own.  But what if the Client App wants to
distinguish between a message that:

* It has created, but not yet sent to the router
* Has been sent to the router (or we think it has)
* Has been acknowledged by the router as having been received (but
hasn't been sent to the ECN yet)
* Has been sent by the router to the ECN (or the router thinks it has)

And so on.  Different systems may want to have some sort of feedback
for any/all of these events, so I can see a need for finer-grained
status codes.  As with routing FIX in general though, the more hops
you have, the more fields or codes you need if you want to capture all
of the this information.  This can turn into a mess pretty fast.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

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

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

Caleb -

That is exactly our issue. We could be even more fine-grained than we
are, but we attempted to minimize the number of extensions we were
making to the protocol. We felt that adding just the three new extended
field values provided enough information for our clients to know the
true state of their order without causing them to have to do a lot of
coding to support our non-standard values.

We could easily have used another 4-5 statuses, but the net value to
our clients was limited.

- Brian Erst
Thynk Software, Inc.

--- Caleb Epstein <cal...@gm...> wrote:

> On 6/3/05, James C. Downs <jc...@co...> wrote:
> 
> > 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?
> 
> I think the answer depends on how fine-grained you want to make the
> information you pass back to clients of a system.  Especially if
> messages take more than one hop before they go out the door. 
> Consider
> for example this system:
> 
> Client app -> FIX router -> ECNs
> 
> If the FIX router were purely a message-passing application, it would
> just rely on the ECNs to generate all of the execution reports and
> wouldn't generate any of its own.  But what if the Client App wants
> to
> distinguish between a message that:
> 
> * It has created, but not yet sent to the router
> * Has been sent to the router (or we think it has)
> * Has been acknowledged by the router as having been received (but
> hasn't been sent to the ECN yet)
> * Has been sent by the router to the ECN (or the router thinks it
> has)
> 
> And so on.  Different systems may want to have some sort of feedback
> for any/all of these events, so I can see a need for finer-grained
> status codes.  As with routing FIX in general though, the more hops
> you have, the more fields or codes you need if you want to capture
> all
> of the this information.  This can turn into a mess pretty fast.
> 
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com
>