FIX architecture questions

, ,
1

Imported from previous forum

2

Hi - Any input on the following FIX architecture questions is greatly appreciated!

  1. Are FIX engines are primarily used for b2b communication: ie. broker to broker? Or, are FIX engines primarily/extensively used in-house for exchanging buy/sell/quote requests amoungst brokers and (external) web clients of one company?

  2. Does a brokerage typically have a central FIX server connected to the in-house OMS that relays executions to in-house FIX “clients”? Or, do many in-house FIX engines connect to the OMS separately?

  3. A FIX Engine often communicates with an OMS, but using what protocol, FIX? Or, would this communication from FIX Engine to OMS be handled by application programming?

  4. Last question: In the case of brokerages with web clients like schwab, etrade, fidelity… how might the JSP process spawn a FIX request? Presumably, the fix process is already running as a separate process, so some form of IPC is needed, what might be a good choice?

Thanks in advance!

3

  1. All of the above. FIX is definitely used between buy-sides and sell-sides, and sell-sides and exchanges, for pre-trade, trade and post-trade activities. And it’s also often used as “middleware” internally between various desks and departments within an organization for some of those same activities.

  2. Brokerages configure this in a variety of ways. A smaller shop might have one OMS and one FIX engine; as connections from customers and to exchanges grow in number, they might have one OMS but more than one FIX engine; as the complexity of trading grows they might have more than one OMS and several FIX engines.

  3. It is usually up to the developer to integrate the OMS with the FIX engine, and the choice of protocols is generally limited to what the FIX engine offers. Robust FIX engines offer multiple options including using it in-process or out-of-process with your OMS, multiple choices of programming languages, and even support of popular middleware like TIBCO.

  4. The JSPs behind some of the retail brokerage sites you mention probably don’t invoke FIX services directly. I would imagine that they invoke other application services related to order management, and those eventually make the decisions as to what messages to send and when. That being said, how those application services are architected to interact with FIX then depends on your choices in #3.

Hope that helps a bit,

David Rhodes
TransactTools

Hi - Any input on the following FIX architecture questions is greatly
appreciated!

  1. Are FIX engines are primarily used for b2b communication: ie. broker
    to broker? Or, are FIX engines primarily/extensively used in-house
    for exchanging buy/sell/quote requests amoungst brokers and
    (external) web clients of one company?

  2. Does a brokerage typically have a central FIX server connected to the
    in-house OMS that relays executions to in-house FIX “clients”? Or, do
    many in-house FIX engines connect to the OMS separately?

  3. A FIX Engine often communicates with an OMS, but using what protocol,
    FIX? Or, would this communication from FIX Engine to OMS be handled
    by application programming?

  4. Last question: In the case of brokerages with web clients like
    schwab, etrade, fidelity… how might the JSP process spawn a FIX
    request? Presumably, the fix process is already running as a separate
    process, so some form of IPC is needed, what might be a good choice?

Thanks in advance!

4

[ original email was from jeff yancey - jyancey@tpg.com.au ]
> You will also find that Stock Exchanges are starating to use FIX for both trading and for market data. The Australian and Singapore Stock Exchanges provide a FIX interface to their trading systems.

  1. All of the above. FIX is definitely used between buy-sides and sell-
    sides, and sell-sides and exchanges, for pre-trade, trade and post-
    trade activities. And it’s also often used as “middleware” internally
    between various desks and departments within an organization for some
    of those same activities.

  2. Brokerages configure this in a variety of ways. A smaller shop might
    have one OMS and one FIX engine; as connections from customers and to
    exchanges grow in number, they might have one OMS but more than one
    FIX engine; as the complexity of trading grows they might have more
    than one OMS and several FIX engines.

  3. It is usually up to the developer to integrate the OMS with the FIX
    engine, and the choice of protocols is generally limited to what the
    FIX engine offers. Robust FIX engines offer multiple options
    including using it in-process or out-of-process with your OMS,
    multiple choices of programming languages, and even support of
    popular middleware like TIBCO.

  4. The JSPs behind some of the retail brokerage sites you mention
    probably don’t invoke FIX services directly. I would imagine that
    they invoke other application services related to order management,
    and those eventually make the decisions as to what messages to send
    and when. That being said, how those application services are
    architected to interact with FIX then depends on your choices in #3.

Hope that helps a bit,

David Rhodes TransactTools

Hi - Any input on the following FIX architecture questions is greatly
appreciated!

  1. Are FIX engines are primarily used for b2b communication: ie.
    broker to broker? Or, are FIX engines primarily/extensively used
    in-house for exchanging buy/sell/quote requests amoungst brokers
    and (external) web clients of one company?

  2. Does a brokerage typically have a central FIX server connected to
    the in-house OMS that relays executions to in-house FIX “clients”?
    Or, do many in-house FIX engines connect to the OMS separately?

  3. A FIX Engine often communicates with an OMS, but using what
    protocol, FIX? Or, would this communication from FIX Engine to OMS
    be handled by application programming?

  4. Last question: In the case of brokerages with web clients like
    schwab, etrade, fidelity… how might the JSP process spawn a FIX
    request? Presumably, the fix process is already running as a
    separate process, so some form of IPC is needed, what might be a
    good choice?

Thanks in advance!