Imported from previous forum
[ original email was from Danny Shobrook - dzshobrook@dial.pipex.com ]
As more and more engines come on line with alot of people using networks rather than point to point connections might it not be worthwhile having a "What messages I support" message rather then sending off a cancel message to someone who has not implemented it and not get any reply?
Failing this have a Message type not implemented flag in a reject message?
[ original email was from Steve Glickstein - sglickstein@warburg.com ]
It sound to me like the real problem you are addressing is the potential fragmentation of message formats. Instead of changing the message structure to help firms that don’t support the published FIX standard, shouldn’t we seek better ways of promoting the published standards.
A certification process should take us in the right direction.
> As more and more engines come on line with alot of people using networks rather than point to point connections might it not be worthwhile having a "What messages I support" message rather then sending off a cancel message to someone who has not implemented it and not get any reply?
>
> Failing this have a Message type not implemented flag in a reject message?
>
[ original email was from Danny Shobrook - dzshobrook@dial.pipex.com ]
> It sound to me like the real problem you are addressing is the potential fragmentation of message formats. Instead of changing the message structure to help firms that don’t support the published FIX standard, shouldn’t we seek better ways of promoting the published standards.
I think you’ve misunderstood me. I don’t mean that you should be allowed to fragment the message format. What I meant is that as FIX grows both across various different security types and for firms of various different sizes then they are going to have different requirements. Now at the mo this is not a problem because to hook up to someone you pick up the phone say “I want this, that and the other”, they tell what they can and cannot support. What I am suggesting is that this be acheivable electronically. For instance, how many people are supporting Allocations and Settlement Instructions in a live environment? Does this mean their engine is not FIX compliant or just there has been no demand for it to justify the additional complexity and cost? Once they offer it do they pick up the phone to all their clients? What if they are going over a Third-party network?
I think there is clearly a core portion of the FIX protocol that must be implemented for one engine to talk to another. But every single last tag?
Query: What happens if I send Warburgs Asset Management a settlement instructions or a Forex quote? How should our engine interpret a lack of response?
> > It sound to me like the real problem you are addressing is the potential fragmentation of message formats. Instead of changing the message structure to help firms that don’t support the published FIX standard, shouldn’t we seek better ways of promoting the published standards.
>
> I think you’ve misunderstood me. I don’t mean that you should be allowed to fragment the message format. What I meant is that as FIX grows both across various different security types and for firms of various different sizes then they are going to have different requirements. Now at the mo this is not a problem because to hook up to someone you pick up the phone say “I want this, that and the other”, they tell what they can and cannot support. What I am suggesting is that this be acheivable electronically. For instance, how many people are supporting Allocations and Settlement Instructions in a live environment? Does this mean their engine is not FIX compliant or just there has been no demand for it to justify the additional complexity and cost? Once they offer it do they pick up the phone to all their clients? What if they are going over a Third-party network?
>
> I think there is clearly a core portion of the FIX protocol that must be implemented for one engine to talk to another. But every single last tag?
>
> Query: What happens if I send Warburgs Asset Management a settlement instructions or a Forex quote? How should our engine interpret a lack of response?
>
I am not proposing any answers, but since there are a bunch of related issues here, we should break them up into components:
-
Certification - Would there be different levels, such as the top level would be the ability to handle all the FIX message types, and another level would be a subset such as IOIs, orders and executions. This might get confusing. Also, who will perform certification and how will everyone be notified? Also, would there be application level certification, such as that the application is doing the right thing when the message is received?
-
Positive response to FIX messages which the engine does not handle - this is the case where instead of ignoring a message, the response could be that this engine does not support that message.
-
Notification of supported messages - This is where the FIX engines would trade a list, presumably on login, of which messages are supported. This info would then be passed back to the application which would have to keep track of which targets can handle which message types. I’m wondering if anyone has built this capability into a trading system today?
Summary - right now determining if a target can handle a particular message type is a manual process, with the assumption being that it is easy to track if there are not that many connections. When there are lots of connections, the problem would be compounded. And there isn’t a central source to reference for this information.
[ original email was from Danny Shobrook - dzshobrook@dial.pipex.com ]
> 1) Certification - Would there be different levels, such as the top level would be the ability to handle all the FIX message types, and another level would be a subset such as IOIs, orders and executions. This might get confusing. Also, who will perform certification and how will everyone be notified? Also, would there be application level certification, such as that the application is doing the right thing when the message is received?
I cannot see certification being terribly helpfull. It is likely to be very expensive, raising barriers to entry. How do you certify at the application level? Is the OMS vendor, Engine vendor or customer’s fault if - say - the Order Ids generated are invalid? Maybe a reference implementation that folks can test against or the current moves in the XML side to come up with a formal DTD for messages will be more helpfull.
>
> 2) Positive response to FIX messages which the engine does not handle - this is the case where instead of ignoring a message, the response could be that this engine does not support that message.
I think this is vital. There should not have to be any guessing or botches.
>
> 3) Notification of supported messages - This is where the FIX engines would trade a list, presumably on login, of which messages are supported. This info would then be passed back to the application which would have to keep track of which targets can handle which message types. I’m wondering if anyone has built this capability into a trading system today?
At logon sounds good, I had thought of a separate message set but your suggestion is better. Any trading system that does this must obviously step outside the spec. OFX has this capability to query what message sets and features have been implemented.
> Summary - right now determining if a target can handle a particular message type is a manual process, with the assumption being that it is easy to track if there are not that many connections. When there are lots of connections, the problem would be compounded. And there isn’t a central source to reference for this information.
Exactly my point. You could maybe argue that the website is a central refernce but it ain’t something the engine can query on-line. Also it save the relevent bods at the banks getting calls asking “do you offer this?”.
[ original email was from Steve Glickstein - sglickstein@warburg.com ]
> > 1) Certification - Would there be different levels, such as the top level would be the ability to handle all the FIX message types, and another level would be a subset such as IOIs, orders and executions. This might get confusing. Also, who will perform certification and how will everyone be notified? Also, would there be application level certification, such as that the application is doing the right thing when the message is received?
>
> I cannot see certification being terribly helpfull. It is likely to be very expensive, raising barriers to entry. How do you certify at the application level? Is the OMS vendor, Engine vendor or customer’s fault if - say - the Order Ids generated are invalid? Maybe a reference implementation that folks can test against or the current moves in the XML side to come up with a formal DTD for messages will be more helpfull.
>
> >
I don’t have answers but here’s some more food for thought:
What are the goals / purpose of certification? Is one of these goals to let trading partners know the messages each party is capable of accepting / sending? If so, would certification lower barriers to entry by enabling trading partners to quickly know what message types each other supports and the nuances each party requires? Could this be done in an automated method? Could it involve what is suggested in item 3?
> > 2) Positive response to FIX messages which the engine does not handle - this is the case where instead of ignoring a message, the response could be that this engine does not support that message.
> I think this is vital. There should not have to be any guessing or botches.
>
> >
agree
> > 3) Notification of supported messages - This is where the FIX engines would trade a list, presumably on login, of which messages are supported. This info would then be passed back to the application which would have to keep track of which targets can handle which message types. I’m wondering if anyone has built this capability into a trading system today?
>
Again, I don’t have any answers, just some more food for thought.
This issue extends to specific tag values. For example, what happens if an implementation only supports tag 44 =1 or 2? Should the exchange of message types include tag values as well?
Can we define higher levels of supported messages groups? Can we provide incentives for implementations to operate at one of these pre-defined levels? Are existing FIX implementations already operating at some yet-to-be defined common message groupings?
Instead of exchanging a list of specific message types and tag values supported, can we exchange a message group identifier? Can we consider this message exchange to be a certification message?
>
> > Summary - right now determining if a target can handle a particular message type is a manual process, with the assumption being that it is easy to track if there are not that many connections. When there are lots of connections, the problem would be compounded. And there isn’t a central source to reference for this information.
>
> Exactly my point. You could maybe argue that the website is a central refernce but it ain’t something the engine can query on-line. Also it save the relevent bods at the banks getting calls asking “do you offer this?”.
>
Agree
[ original email was from Danny Shobrook - dzshobrook@dial.pipex.com ]
After some discussion with others, the consensus was:
That it should be part of the session layer to reject any messages that your engine does not understand the type. This removes any doubt.
I personally think it would still be a good to idea to make security type mandatory and allow the executing party to be able to reject based on non -tradeable security type. Otherwise if you are only expecting cash-equities and you get a option order, unless you check the security type and look for those extra tags - which your old engine may not do - it will think it an equity deal.