Imported from previous forum
All
According to the FIX Specification does my 3rd party have a responsibility to store business messaging, or, should they be acting as an invisible entity and simply pass the messages between clients.
Further, in response to an outage does the FIX spec allow me to expect my third party to store all relevent business messaging or is it a matter
of my third party only being responsible for forwarding the messages between myself and my counter-party?
Regards
Mike
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> According to the FIX Specification does my 3rd party have a responsibility to store business messaging, or, should they be acting as an invisible entity and simply pass the messages between clients.
>
> Further, in response to an outage does the FIX spec allow me to expect my third party to store all relevent business messaging or is it a matter
> of my third party only being responsible for forwarding the messages between myself and my counter-party?
I am assuming by third party you are referring to a FIX message routing network, where you are using OnBehalfOf/DeliverTo, and where the network is just doing message-level routing, not a service bureau that gets involved at an application layer.
Generally, the FIX Protocol tries not to dictate how firms should do business. The guidelines for FIX routing networks in the spec are few, and I think the only thing specifically applicable to routing networks is the clarification of the OnBehalfOf and DeliverTo fields.
In my opinion, there are several approaches to this issue:
It is, in my view, easiest for the third party to store every applcation message for the duration of the FIX session (usually a day). So if A sends a message to X, which forwards that message to B, and B asks X for a Resend Request, it is easiest if X can simply respond from its database of messages.
Alternately, X can translate that Resend Request from B into Resend Requests to A and everyone else sending messages to B that wound up in the range B asked for. X can then assemble the results (i.e. whether the parties chose to resend the message in question or gap filled over it) to assemble a response for B. It could be a very slow process as X must respond to B’s Resend Request in order and cannot send any other message to B until it finishes, hence X depends on everyone routing messages to B to respond promptly to the Resend Requests X sent. Further, what if A is down when B sends the Resend Request? X certainly can’t ask A, and if A is the sell-side and the message in question was an Execution Report representing a trade, there will likely be a trade break. The complexity here is staggering, and I would be very surprised if someone was able to pull off such an implementation and scale it.
It also is possible, and compliant with the FIX Protocol, for X to gap fill over every Resend Request it receives. This might be fine for data that has little to no value if not sent in realtime, i.e. IOIs or Market Data. But it would be unusable for order routing. (Even if the buy side doesn’t want orders retransmitted, the sell side certainly will insist on Execution Reports being retransmitted.)