Valid values for Side (54) in IOI <6> message

, ,
1

Imported from previous forum

2

[ original email was from John Harris - john.harris@bondmart.com ]
Hi,

In the specification of the Indication of Interest <6> message in FIX versions 5.0 SP2 and 4.4 (if not others), it appears that the range of valid values for the Side (54) field is a subset of those specified for the Side field in the data dictionary.

  1. Is that actually the case or an error in the specs?

  2. If actually the case, what is the thinking behind the limitation? Why would “cross,” for example, be an invalid Side value for an Indication of Interest.

Thank you.

Best,
John

3

Hi John

I don’t pretend to be an expert on IOI’s but seeing that nobody else has responded, I’ll have a go…

I think IOI’s are a bit like a dating service - you are advertising for a partner (to trade with). I don’t like where the dating analogy is heading when it comes to crossing, so I’ll switch metaphors to playing cards and say that with crossing you are playing solitaire - no need to advertise for a partner, you are doing it all by yourself.

John

Hi,

In the specification of the Indication of Interest <6> message in FIX versions 5.0 SP2 and 4.4 (if not others), it appears that the range of valid values for the Side (54) field is a subset of those specified for the Side field in the data dictionary.

  1. Is that actually the case or an error in the specs?

  2. If actually the case, what is the thinking behind the limitation? Why would “cross,” for example, be an invalid Side value for an Indication of Interest.

Thank you.

Best,
John

4

[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, John - not least for combining dating and card-playing metaphors in one message! I’ll leave it at that, as well.

Interestingly, a multi-leg IOI accepts “cross” as a valid value for side.

Why “cross” is a valid value for “side” is a mystery in and of itself.

Unless someone has an explanation, I will consider this an error in the spec. “Side” should take only two values: buy or sell. There are no other possibilities.

Hi John

I don’t pretend to be an expert on IOI’s but seeing that nobody else has responded, I’ll have a go…

I think IOI’s are a bit like a dating service - you are advertising for a partner (to trade with). I don’t like where the dating analogy is heading when it comes to crossing, so I’ll switch metaphors to playing cards and say that with crossing you are playing solitaire - no need to advertise for a partner, you are doing it all by yourself.

John

Hi,

In the specification of the Indication of Interest <6> message in FIX versions 5.0 SP2 and 4.4 (if not others), it appears that the range of valid values for the Side (54) field is a subset of those specified for the Side field in the data dictionary.

  1. Is that actually the case or an error in the specs?

  2. If actually the case, what is the thinking behind the limitation? Why would “cross,” for example, be an invalid Side value for an Indication of Interest.

Thank you.

Best,
John

5

I went looking and found out that Side=Cross was added with FIX 4.1 back in 1998. The scenario is still part of the tag description, i.e. “orders where counterparty is an exchange” but I do not know what that means. However, Volume 4 of the spec defines the usage of Side=Cross for cases where you want to use NewOrderSingle for the submission of cross orders. Cross order messages were only added with FIX 4.3. The idea is to send in two NewOrderSingle messages with Side=Cross to avoid the first one from being executed against other orders. Obviously, the second order needs to have some reference to the first to allow the recipient to put the two together.
I also found a usage that I would classify as a violation. The driver in that example is the desire to convey both sides of an execution with an ExecutionReport message. The spec clearly says that execution reporting for cross orders is done by side. In the example (from 2007), the standard CumQty and LeavesQty tags are used but set to zero. That is a violation in itself. Additonally, user defined fields Buy(Sell)CumQty and Buy(Sell)LeavesQty were used to convey the quantities of both sides in a single message. I consider the usage of UDFs to replace key fields such as Cum/LeavesQty as a violation. If the UDFs were registered at the time I do not know but the tag numbers are now registered to someone and something else.
A last comment on valid values of a field. It is intentional to limit the set of valid values for a given field for a certain context, i.e. Side=Cross does not apply to IOIs. The context can be technical (a message type) or functional (business workflow). The problem is that we have too little information of this nature in the spec today. FIXwiki will certainly help by being able to add such usage notes if they are not already part of the underlying repository.
Regards,
Hanno.

Thank you, John - not least for combining dating and card-playing metaphors in one message! I’ll leave it at that, as well.

Interestingly, a multi-leg IOI accepts “cross” as a valid value for side.

Why “cross” is a valid value for “side” is a mystery in and of itself.

Unless someone has an explanation, I will consider this an error in the spec. “Side” should take only two values: buy or sell. There are no other possibilities.

6

[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Hanno. Several thoughts in response:

  1. A “cross” is a trade effected by reference to a third-party price. Buyer and seller agree to use a price established in a venue independent of each of them as the basis for their own exchange of goods for money (e.g., “let’s compute the midpoint between bid and offer for [instrument] as quoted at [venue] and agree use that as the price for our trade”). A cross may be negotiated over-the-counter and reported to an exchange; it may be negotiated on an exchange; it may even be effected in markets for which there is no functioning exchange. A cross requires a seller and a buyer. In and of itself, it does not - and cannot - express “sidedness.” So it should not be a valid value for “side” at all. In the protocol, cross should either take its own message template or be expressed through one or more price fields.

  2. Limiting or relating valid values on the basis of business or technical context is fine (though perhaps ideally avoided - will have to think about that). Of course, such context-dependencies should be specified.

  3. FIXwiki is a terrific resource - thank you, John C. - but I am doubtful it will be the most efficient way to re-factor FIX. In fact, I am growing increasingly doubtful that re-factoring FIX is a worthwhile or even viable enterprise. My suspicion is that FIX as it stands today should be culled for business requirements and those requirements should be used as the basis for a new protocol; otherwise, FIX 5.0 SP2 (with errata) should be the last version of FIX in present form. It and previous versions will continue to be useful for many years to come, but they are not worth additional development as protocols.

I went looking and found out that Side=Cross was added with FIX 4.1 back in 1998. The scenario is still part of the tag description, i.e. “orders where counterparty is an exchange” but I do not know what that means. However, Volume 4 of the spec defines the usage of Side=Cross for cases where you want to use NewOrderSingle for the submission of cross orders. Cross order messages were only added with FIX 4.3. The idea is to send in two NewOrderSingle messages with Side=Cross to avoid the first one from being executed against other orders. Obviously, the second order needs to have some reference to the first to allow the recipient to put the two together.
I also found a usage that I would classify as a violation. The driver in that example is the desire to convey both sides of an execution with an ExecutionReport message. The spec clearly says that execution reporting for cross orders is done by side. In the example (from 2007), the standard CumQty and LeavesQty tags are used but set to zero. That is a violation in itself. Additonally, user defined fields Buy(Sell)CumQty and Buy(Sell)LeavesQty were used to convey the quantities of both sides in a single message. I consider the usage of UDFs to replace key fields such as Cum/LeavesQty as a violation. If the UDFs were registered at the time I do not know but the tag numbers are now registered to someone and something else.
A last comment on valid values of a field. It is intentional to limit the set of valid values for a given field for a certain context, i.e. Side=Cross does not apply to IOIs. The context can be technical (a message type) or functional (business workflow). The problem is that we have too little information of this nature in the spec today. FIXwiki will certainly help by being able to add such usage notes if they are not already part of the underlying repository.
Regards,
Hanno.

Thank you, John - not least for combining dating and card-playing metaphors in one message! I’ll leave it at that, as well.

Interestingly, a multi-leg IOI accepts “cross” as a valid value for side.

Why “cross” is a valid value for “side” is a mystery in and of itself.

Unless someone has an explanation, I will consider this an error in the spec. “Side” should take only two values: buy or sell. There are no other possibilities.

7

I concur that some of the design decisions in FIX are not optimal but they were taken at a specific point in time within a given scope and context of FIX. The value of a standard also comes from the fact that it is not changed too much over time, rather extended.
I was not involved with FIX back in 1998 but it could have been as simple as this: we need to submit cross orders, we have a message “OrderSingle” which would fit apart from Side field, Side is mandatory so we cannot just leave it out, let’s add a value “Cross” which will identify the intent of submitting two orders that constitute a cross. FIX offers NewOrderCross (as of 4.3) to do it “the right way” but supports alternate means for those that cannot move beyond 4.2.
I am not primarily defending the original design decision, I am advocating to resist the temptation to “scrap it all, let’s get it right this time” approach that I read in your comment. It would be great to go down that route but we need to be realistic and pragmatic. The breadth of FIX scope together with the size of the installed base are valid arguments to maintain what exists and only apply incremental changes that the community can transition to over time. FIX 5 was believed to be such an incremental transition (only a few fields in the standard header need to be changed). 4 years later, look at how slowly FIX 5 has been adopted. It is finally picking up, supported the FIX 5 adoption from exchanges, clearing houses and regulators.
Regards,
Hanno.

  1. A “cross” is a trade effected by reference to a third-party price. Buyer and seller agree to use a price established in a venue independent of each of them as the basis for their own exchange of goods for money (e.g., “let’s compute the midpoint between bid and offer for [instrument] as quoted at [venue] and agree use that as the price for our trade”). A cross may be negotiated over-the-counter and reported to an exchange; it may be negotiated on an exchange; it may even be effected in markets for which there is no functioning exchange. A cross requires a seller and a buyer. In and of itself, it does not - and cannot - express “sidedness.” So it should not be a valid value for “side” at all. In the protocol, cross should either take its own message template or be expressed through one or more price fields.
8

[ original email was from John Harris - john.harris@bondmart.com ]
Hanno,

You misread my comment. I did not advocate scrapping any version of FIX. Rather, I advocate the creation of a new set of protocols that people may adopt over time.

Best,
John

I concur that some of the design decisions in FIX are not optimal but they were taken at a specific point in time within a given scope and context of FIX. The value of a standard also comes from the fact that it is not changed too much over time, rather extended.
I was not involved with FIX back in 1998 but it could have been as simple as this: we need to submit cross orders, we have a message “OrderSingle” which would fit apart from Side field, Side is mandatory so we cannot just leave it out, let’s add a value “Cross” which will identify the intent of submitting two orders that constitute a cross. FIX offers NewOrderCross (as of 4.3) to do it “the right way” but supports alternate means for those that cannot move beyond 4.2.
I am not primarily defending the original design decision, I am advocating to resist the temptation to “scrap it all, let’s get it right this time” approach that I read in your comment. It would be great to go down that route but we need to be realistic and pragmatic. The breadth of FIX scope together with the size of the installed base are valid arguments to maintain what exists and only apply incremental changes that the community can transition to over time. FIX 5 was believed to be such an incremental transition (only a few fields in the standard header need to be changed). 4 years later, look at how slowly FIX 5 has been adopted. It is finally picking up, supported the FIX 5 adoption from exchanges, clearing houses and regulators.
Regards,
Hanno.

  1. A “cross” is a trade effected by reference to a third-party price. Buyer and seller agree to use a price established in a venue independent of each of them as the basis for their own exchange of goods for money (e.g., “let’s compute the midpoint between bid and offer for [instrument] as quoted at [venue] and agree use that as the price for our trade”). A cross may be negotiated over-the-counter and reported to an exchange; it may be negotiated on an exchange; it may even be effected in markets for which there is no functioning exchange. A cross requires a seller and a buyer. In and of itself, it does not - and cannot - express “sidedness.” So it should not be a valid value for “side” at all. In the protocol, cross should either take its own message template or be expressed through one or more price fields.
9

Maybe “scrapping” was too harsh a term. A new set of protocols creates the notion of having to make a choice between the “old” (not developed any further) and the “new” set of protocols. The larger the gap between the two is perceived, the lower the incentive for adoption unless very specific business needs arise. Maybe it is just a marketing issue but the FIX 5 experience shows how hard it can be, even if it was just the next major version of an existing, well-known protocol. For example, it boils down to what people believe they will have to do to take advantage of a high performance FIX that is currently being developed by a FIX Working Group. For example, a binary encoding can be completely hidden to the application level by being provided as an integral part of existing FIX engines. That is much easier to “sell” than a change in transport/recovery concepts or semantic changes on the application level which is the toughest bit. Removing valid values from existing FIX fields represents a semantic change and would trigger needless debate even if it could result in a cleaner spec. Primary objective is FIX adoption and not to get rid of mis-use or mis-interpretation of the spec which is simply impossible. FPL can only incentivise and/or support proper use, e.g. by providing guidelines and tools such as the FIX Repository, FIXML Schema, FIXimate and FIXwiki.

Hanno,

You misread my comment. I did not advocate scrapping any version of FIX. Rather, I advocate the creation of a new set of protocols that people may adopt over time.

Best,
John

I concur that some of the design decisions in FIX are not optimal but they were taken at a specific point in time within a given scope and context of FIX. The value of a standard also comes from the fact that it is not changed too much over time, rather extended.
I was not involved with FIX back in 1998 but it could have been as simple as this: we need to submit cross orders, we have a message “OrderSingle” which would fit apart from Side field, Side is mandatory so we cannot just leave it out, let’s add a value “Cross” which will identify the intent of submitting two orders that constitute a cross. FIX offers NewOrderCross (as of 4.3) to do it “the right way” but supports alternate means for those that cannot move beyond 4.2.
I am not primarily defending the original design decision, I am advocating to resist the temptation to “scrap it all, let’s get it right this time” approach that I read in your comment. It would be great to go down that route but we need to be realistic and pragmatic. The breadth of FIX scope together with the size of the installed base are valid arguments to maintain what exists and only apply incremental changes that the community can transition to over time. FIX 5 was believed to be such an incremental transition (only a few fields in the standard header need to be changed). 4 years later, look at how slowly FIX 5 has been adopted. It is finally picking up, supported the FIX 5 adoption from exchanges, clearing houses and regulators.
Regards,
Hanno.

  1. A “cross” is a trade effected by reference to a third-party price. Buyer and seller agree to use a price established in a venue independent of each of them as the basis for their own exchange of goods for money (e.g., “let’s compute the midpoint between bid and offer for [instrument] as quoted at [venue] and agree use that as the price for our trade”). A cross may be negotiated over-the-counter and reported to an exchange; it may be negotiated on an exchange; it may even be effected in markets for which there is no functioning exchange. A cross requires a seller and a buyer. In and of itself, it does not - and cannot - express “sidedness.” So it should not be a valid value for “side” at all. In the protocol, cross should either take its own message template or be expressed through one or more price fields.
10

Hanno,

I recall some additional usage scenarios for Side=Cross from the US equities world.

Scenario: A buy-side institution wants to buy 1 million shares IBM. The national best offer is $123.45. A sell-side broker has 1 million shares IBM in inventory, and wishes to sell to the buy-side at an arranged price of, say, $123.46. This transaction is referred to as a “cross.” In order to guarantee that the buy-side gets a fair price, the broker sends the “cross” to an exchange. OrderQty=1 million Side=Cross LastPx=123.46.

The exchange sees that the cross is outside the NBBO. So the exchange executes the cross against a 1000 share order at $123.45, sending the broker a partial fill with Side=Buy LastQty=1000 LastPx=123.45. Then the exchange has an order for 2000 shares on its books at $123.46 which has time priority over the cross, so it sends Side=Buy LastQty=2000 LastPx=123.46. Then it allows the remainder of the cross to proceed: Side=Cross LastQty=997000 LastPx=123.46.

The broker has, effectively, bought 3000 shares of IBM from the exchange, which it passes on to the buy-side, and has been given permission to cross the remaining 997,000 shares with the buy-side at $123.46.

An IOI with a side of Cross does make sense in this context. Whereas an IOI with a side of Buy or Sell indicates an interest to buy or sell, an IOI with a side of Cross implies that the party sending it intends to cross shares at a price, but is looking for price improvement before doing so.