[This message was posted by John  Peng of IIROC <[email protected]> to 
the "4.2 Changes" discussion forum at http://fixprotocol.org/discuss/5. You can 
reply to it on-line at http://fixprotocol.org/discuss/read/df60c2c2 - PLEASE DO 
NOT REPLY BY MAIL.]

I take exception on the answer to question (5).  A sell side can certainly use 
a single FIX engine to handle the communication with both tthe buy side and the 
exchange. 

A typical example is an order routing engine at brokage. The broker firm could 
"inject" their business logic between the in-orders and the out-orders.




> Note my answer(s) below
> 
> (1) FIX is primarily used for buy-side to sell-side communication.
> (2) FIX is also used for sell-side to exchange communication.
> 
> FIX is being used for both of the above.
> 
> (3) For FIX communication between buy-side and sell-side, we would need
>     a FIX engine on both sides and a session needs to be maintained
>     between the 2 engines for any communication to happen.
> 
> Yes
> 
> (4) For FIX communication between sell-side and exchange, we would need
>     a FIX engine on both sides and a session needs to be maintained
>     between the 2 engines for any communication to happen.
> 
> Yes
> 
> (5) Assuming the above is true, I believe the sell-side can use a single
>     FIX engine for communication with buy-side as well as exchange.
> 
> No. There is one Session Acceptor FIX engine which receives inbound FIX
> Sessions from Buy side(s). Another Session initiator FIX engine sends
> outbound FIX Sessions to Exchanges / other venues. Between the inbound
> FIX engine and the outbound FIX engine there is an application which
> applies business logic and decides which exchange would receive the
> order or slice of the order. Since one is a Session Acceptor and another
> is a Session initiator, two FIX engines are needed at a Sell side.
> 
> (6) Most of the sample code that I see is a buy-side communicating with
>     a sell-side wherein the sell-side simulates a response. I want to
>     understand the end-to-end scenario with an exchange also in picture.
>     Lets say buy-side places an order. Sell-side receives the order and
>     instead of simulating a response needs to send the order to the
>     exchange. I am imagining that the sell-side application picks up the
>     order from buy-side-sell-side-session, probably makes changes to the
>     sendercompid and targetcompid, and sends the order on the sell-side-
>     exchange session to the exchange. Thus an end-to-end scenario will
>     always involve 2 FIX sessions. Is this correct?
> 
> The two FIX Sessions one between Buy side <-> Sell side and between Sell
> side <-> Exchange are independent of each other. Your description of end-to-
> end scenario is correct.
> 
> (7) I have some folks telling me that "buy sides will not have a FIX
>     engine but they will be able to send FIX messages using some
>     adapter. Only the sell side will have a fix engine to receive and
>     process these messages.". I believe this is incorrect. Am I correct?
> 
> Not always, many buy sides would have a FIX engine. There could be
> scenarios where the buy side does not have a FIX engine but instead
> connects to a service provider who translates between non-FIX to FIX
> using an adapter and sends out FIX orders to the Sell side and
> translates the FIX executions into non-FIX format and hands it out to
> the Buy side.
> 
> The converse is also true. There are exchanges which have non-FIX
> interfaces in which case a service provider translates from FIX to non-
> FIX Exchange specific format and back.
> 
> > I have a few BASIC questions bothering me and would like to understand
> > if I am on the right track. Can you please confirm/answer the
> > following:
> >
> > (1) FIX is primarily used for buy-side to sell-side communication.
> >
> > (2) FIX is also used for sell-side to exchange communication.
> >
> > (3) For FIX communication between buy-side and sell-side, we would
> >     need a FIX engine on both sides and a session needs to be
> >     maintained between the 2 engines for any communication to happen.
> >
> > (4) For FIX communication between sell-side and exchange, we would
> >     need a FIX engine on both sides and a session needs to be
> >     maintained between the 2 engines for any communication to happen.
> >
> >(5)    Assuming the above is true, I believe the sell-side can use a
> >                                  single
> >      FIX engine for communication with buy-side as well as exchange.
> >
> > (6) Most of the sample code that I see is a buy-side communicating
> >     with a sell-side wherein the sell-side simulates a response. I
> >     want to understand the end-to-end scenario with an exchange also
> >     in picture. Lets say buy-side places an order. Sell-side receives
> >     the order and instead of simulating a response needs to send the
> >     order to the exchange. I am imagining that the sell-side
> >     application picks up the order from buy-side-sell-side-session,
> >     probably makes changes to the sendercompid and targetcompid, and
> >     sends the order on the sell-side- exchange session to the
> >     exchange. Thus an end-to-end scenario will always involve 2 FIX
> >     sessions. Is this correct?
> >
> > (7) I have some folks telling me that "buy sides will not have a FIX
> >     engine but they will be able to send FIX messages using some
> >     adapter. Only the sell side will have a fix engine to receive and
> >     process these messages.". I believe this is incorrect. Am I
> >     correct?


[You can unsubscribe from this discussion group by sending a message to 
mailto:[email protected]]

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Financial Information eXchange" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/fix-protocol?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to