Multi-party FIX network example ...


Usually, FIX connections are point-to-point (client-broker). Appreciate if someone can give an example of any existing multi-party FIX networks (may be pub/sub sort of) ? Or, is the privacy of data always supersedes any such requirements.


Hello Arvind,

for the pure ordering, only point-to-point connections make sense for me.

With regard to market data distribution, e.g. Deutsche Börse uses a multi-case network based on FAST encoded FIX message AFAIK.

Cheers, Jörg

Hello Jörg,

Thanks for your reply. That’s what I suspected too!

But, I am also thinking what if ordering can be taken care of despite being part of a network where messages are routed from multiple parties to multiple parties. Can such a network be beneficial to all the participants and potentially create more market places where multi-party communication (for example, collateral based trading etc.) can lead to further trading on the network.

Is there any other reason which I am missing because of which such a network never (or rarely) existed ? What are the pitfalls if we move from point-to-point to publish-subscribe paradigm (if data privacy can be taken care of) ?


@arvindt, FIX is a point-to-point protocol for transactions, e.g. order handling. This includes the ability for retransmissions. There are FIX hubs out there that can route between multiple parties. However, it also involves point-to-point connections between the hub and its users, i.e. no pub-sub model. Market data via multicast over UDP is rarely provided point-to-point and instead published only once together with a (fee-based) subscription model.

Thanks. So, I guess, all along replaying of the messages has been the key reason behind FIX implementation as point-to-point.

What if there is a pub-sub network where replaying of the messages can be provided for, and privacy of the trades is also maintained. Obviously, then multiple parties can engage each other on a transaction (for example, collateral managed trading).

Are there any pitfalls to such an approach ? Is there any other reason I am missing because of which point-to-point is almost always used in the FIX trading world ?

Appreciate your inputs.

Pub-sub is a paradigm that is intended for use cases where messages only need to flow in one and not both directions. Replay is not the key point here. A hub and spokes model is the paradigm for messages flowing in both directions. Pub-sub does not allow the sender to specify the recipient. It is the recipient’s choice whether to subscribe or not. It does not make sense to “publish” an order and multiple venues subscribe to that and more than one of them execute the order. The “publisher” only wants his order executed once.

What is the problem you are trying to solve? As said before, FIX hubs are the solution to multiple parties interacting with each other using FIX.

Usually, Pub-Sub model is in regards to the market data where one source publishes to many subscribers (one-to-many relationship), and I agree replaying messages is not really an issue there.

What I am curious about is Pub-Sub model between multiple parties (many-to-many relationship). Something similar to TibRV (rv daemon) where a network routes the messages among multiple parties.

If that is done, what could be the pitfalls/risks/consequences, or is it feasible at all functionally ?

Or, correct me, if I am missing something completely ?


Hub-Spoke model is close to it. But, then Hub-Spoke comes down to point-to-point which it seems mainly used from replaying point of view. Regards.

My view is that one should not start with a technology and then try to find a problem it can solve. I would start with the business problem and I have not understood the problem you are trying to solve. Replay is not the issue, it is about how a message from the subscriber gets back to the publisher. Such messages are responses or requests started by the counterparty (including the request for a retransmission).

1 Like

There are already few firms that provide such pub-sub models, usually by ‘standing in the middle’ and ‘routing / forwarding messages’.

The most successful in the bond market is Neptune-FI:

I absolutely agree with you. It’s just that you yourself mentioned the problem in the latter part. That is “…it is about how a message from the subscriber gets back to the publisher. …”. What if we try to solve this problem? Won’t that open new possibilities and new market places?

Appreciate your inputs.

This looks interesting! Thanks Yuval. I’ll study this. Regards.

@arvindt: the “problem” has been solved by using the appropriate technology and I do not see any limitations it may pose for business opportunities. I do not want to be disrespectful but it sounds like you are asking me why we do not try to use a tool other than a hammer to hit a nail. Other tools will not work as good as a hammer but why should I even try if a hammer exists? Pub/sub is a great “tool” for market data (prices, quotes, trades,…) and FIX engines with point-to-point connections are often not the right choice with today’s data volumes. It all depends on the use case.

Pub/sub is just one of many tools used by IT and is not the single tool everybody should strive for, i.e. make use of. @yuvalcohen pointed to an example where it has apparently been used, a good place to start to find out which use cases are covered there by pub/sub.

@hanno.klein I respect your view point. Point-to-point may seem like working, but the fact is that there are connection drops (point of failure) and replaying required. Yes, recovery of messages is well taken care of, but there is no denying that the point-to-point requires maintenance (EOD, Sequence nos etc). Often disruptive ideas are found only when we are willing to relook at the same problem with an open mind. Example @yuvalcohen gave is working on exactly what I am looking for. But, they rather surrendered to the existing point-to-point connections to achieve what they’ve built.

Please don’t take me wrong here, but it may be possible (still exploring though …!) to have a FIX network (sort of NYFIX hub-spoke one) where anyone can connect anytime and route their trades to anyone whom they want to, and get confirmation messages back likewise. But, doing all this without the point-to-point logistics, and rather more like pub/sub.

Just in case, I see sufficient grounds to further proceed on this to develop a new product, please let me know if any approvals need to be taken from FIX org ?

Any other approvals/permissions before I can further proceed on this ?


FIX is a free and open standard and does not develop commercial products. FIX does not formally approve or certify products developed by the community. FIX defines standards for the application layer, the encodings and session protocols and publishes them as a (technical) specification.

Great! Thanks @hanno.klein Appreciate it.

One more thing…FIX provides two messages in the infrastructure area to support communication in a “hub and spoke” FIX network:

  • NetworkCounterpartySystemStatusRequest(35=BC)
  • NetworkCounterpartySystemStatusResponse(35=BD)

Thanks @hanno.klein .