Imported from previous forum
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?
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?
I have some information posted at A Person to Person Business Site. Hope it can answer all your questions.
Good luck,
peng
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?
Thank you very much Mahesh. This really helps.
Regarding the last point on service providers that host FIX adapters to do the 2-way conversion:
(1) Is this is a common route that buy-side firms take or is it that the majority of buy-sides would have their own FIX engine?
(2) In case of the service provider approach, is it correct to assume that the service provider would have its FIX engine that would connect to the FIX engine of the sell-side.
(3) What would be some examples of such service providers? Do the trader networks provided by the likes of Fidessa and Fix Flyer belong to this category?
(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?
(1) Is this is a common route that buy-side firms take or is it that the majority of buy-sides would have their own FIX engine?
In percentage terms, I do not have a % number of Buy side firms who directly connect to Sell side using their FIX engine versus those who use service provider(s). FIXGlobal at http://fixglobal.com/ might have the information you are looking for.
(2) In case of the service provider approach, is it correct to assume that the service provider would have its FIX engine that would connect to the FIX engine of the sell-side.
Yes, if a particular sell side is using FIX for inbound connections, then the service provider would have an outbound FIX engine which would act as Session initiator connecting to that sell side’s inbound FIX engine (Session Acceptor).
(3) What would be some examples of such service providers? Do the trader networks provided by the likes of Fidessa and Fix Flyer belong to this category?
There are many networks listed at http://fixprotocol.org/products/3 , you could contact those networks directly to find out if they do non-FIX to FIX connectivity (I would not speak on behalf of any particular vendor).
There are networks which provide FIX to FIX translations, i.e. in a hub and spoke model, the buy side maintains a FIX session with a single FIX version with the network service provider and the network service provider translates it to the FIX version(s) as desired by the different Sell sides. This makes maintainence and certification easier on the buy side, but there is an associated cost.
Thank you very much Mahesh. This really helps.
Regarding the last point on service providers that host FIX adapters to
do the 2-way conversion:(1) Is this is a common route that buy-side firms take or is it that the
majority of buy-sides would have their own FIX engine?(2) In case of the service provider approach, is it correct to assume
that the service provider would have its FIX engine that would
connect to the FIX engine of the sell-side.(3) What would be some examples of such service providers? Do the trader
networks provided by the likes of Fidessa and Fix Flyer belong to
this category?(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?
Hi Mahesh, I checked out the network listings and now I am clear on the service provider concept. Thanks for pointing me in the right direction.
(1) Is this is a common route that buy-side firms take or is it that the
majority of buy-sides would have their own FIX engine?In percentage terms, I do not have a % number of Buy side firms who
directly connect to Sell side using their FIX engine versus those who
use service provider(s). FIXGlobal at http://fixglobal.com/ might have
the information you are looking for.(2) In case of the service provider approach, is it correct to assume
that the service provider would have its FIX engine that would
connect to the FIX engine of the sell-side.Yes, if a particular sell side is using FIX for inbound connections,
then the service provider would have an outbound FIX engine which would
act as Session initiator connecting to that sell side’s inbound FIX
engine (Session Acceptor).(3) What would be some examples of such service providers? Do the trader
networks provided by the likes of Fidessa and Fix Flyer belong to
this category?There are many networks listed at http://fixprotocol.org/products/3 ,
you could contact those networks directly to find out if they do non-
FIX to FIX connectivity (I would not speak on behalf of any
particular vendor).There are networks which provide FIX to FIX translations, i.e. in a hub
and spoke model, the buy side maintains a FIX session with a single FIX
version with the network service provider and the network service
provider translates it to the FIX version(s) as desired by the different
Sell sides. This makes maintainence and certification easier on the buy
side, but there is an associated cost.Thank you very much Mahesh. This really helps.
Regarding the last point on service providers that host FIX adapters
to do the 2-way conversion:(1) Is this is a common route that buy-side firms take or is it that
the majority of buy-sides would have their own FIX engine?(2) In case of the service provider approach, is it correct to assume
that the service provider would have its FIX engine that would
connect to the FIX engine of the sell-side.(3) What would be some examples of such service providers? Do the
trader networks provided by the likes of Fidessa and Fix Flyer
belong to this category?(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?
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?
I don’t agree the anwser to question (5). There shold be one session between client and sell-side broker, or broker and exchange. FIX engine that no matter an accepter, or initiator. After a session established, it should carry FIX messages on both ways (duplex).
good luck,
peng
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?
The inbound and outbound FIX engines are logical units which could be handled by a single physical FIX engine instance.
What are the advantages / disadvantages of this approach of using a single physical FIX Engine instance as inbound session acceptor and outbound session initiator versus using two FIX engine instances one as inbound session acceptor and another as outbound session initiator ? What is the usual industry practice ?
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?
The inbound and outbound FIX engines are logical units which could be
handled by a single physical FIX engine instance.What are the advantages / disadvantages of this approach of using a
single physical FIX Engine instance as inbound session acceptor and
outbound session initiator versus using two FIX engine instances one as
inbound session acceptor and another as outbound session initiator ?
What is the usual industry practice ?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?
One FIX engine to support the connection between client and sell-side. Client always initiates the session by and Sell-side replys <-LOGON>. After the session established, data flows in duplex mode. Tha advantage is only one port used. If the session fail, no data to transfer between both sides. If you have to sessions, and one of them is not connected. What do you do? You can send order to trade, but no report back for updating your order management system.
Good luck,
peng
Hi Changpeng, I think you misinterpreted Mahesh’s response. He is not saying that there will be 2 sessions between the client and sell-side. He was saying that we need 2 FIX engines on the sell-side, one to handle communication with the client and one to handle communication with the exchange. That said, I do agree with John Peng that a single FIX engine at the sell-side should be able to handle both the communication channels.
One FIX engine to support the connection between client and sell-side.
Client always initiates the session by and Sell-side replys ←
LOGON>. After the session established, data flows in duplex mode. Tha
advantage is only one port used. If the session fail, no data to
transfer between both sides. If you have to sessions, and one of them is
not connected. What do you do? You can send order to trade, but no
report back for updating your order management system.Good luck, peng
Hi All,
Just to add my cents to the conversation if I understood. A single fix engine, using one port for two sessions, only a physically issue on the port on both side will stop any data transfer. Otherwise anything else (i.e the connection has been dropped for a sequence issue)will not disable the port so the second session will still live. In layman word the port is like a motrway if one direction or one lane is blocked the others will still functioning.
Hope that help…
Joel
One FIX engine to support the connection between client and sell-side. Client always initiates the session by and Sell-side replys <-LOGON>. After the session established, data flows in duplex mode. Tha advantage is only one port used. If the session fail, no data to transfer between both sides. If you have to sessions, and one of them is not connected. What do you do? You can send order to trade, but no report back for updating your order management system.
The inbound and outbound FIX engines are logical units which could be
handled by a single physical FIX engine instance.What are the advantages / disadvantages of this approach of using a
single physical FIX Engine instance as inbound session acceptor and
outbound session initiator versus using two FIX engine instances one
as inbound session acceptor and another as outbound session initiator
? What is the usual industry practice ?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?
One FIX engine to support the connection between client and sell-side.
Client always initiates the session by and Sell-side replys ←
LOGON>. After the session established, data flows in duplex mode. Tha
advantage is only one port used. If the session fail, no data to
transfer between both sides. If you have to sessions, and one of them is
not connected. What do you do? You can send order to trade, but no
report back for updating your order management system.Good luck, peng