Re: New Program Trading message types for batching
John Harris / BondMart Technologies, Inc.
26 Jan 2011 7:48PM ET
Jim,
Thank you for the link, but respectfully, your explanation promises more than the excerpt delivered. Admittedly, I saw only an excerpt, but the authors posit something (the "order-driven market") that, as they define it, does not exist. Economists and other market theorists frequently (and justifiably) resort to hypothetical constructs, whether for investigative or explanatory purposes, and that is what the authors have done with their order-driven market. They do analogize, in the case of call-auction variants of such markets, to real-world examples. They do not provide a real-world example of the continuous-trading flavor. That doesn't disprove their theory, but I nonetheless believe they are guilty of setting up a straw man on specious legs, only to knock him down in favor of their fair-haired boy - the "quote-driven (or "intermediated") market."
But even setting aside these points, their narrative does not address my objection to the use of the word "quote" in protocol semantics. Seemingly, it does not even address your API concern. Fundamentally, they are making a point about market formation with which I happen to agree: it is difficult to launch, much less sustain, a market without the services of market makers. Who actually disagrees with that? At the very least we should all agree that markets work best when populated with participants of diverse investment horizons, preferences, and constraints. Market makers happen to be people who are skilled at, and comfortable operating under, extremely short investment horizons. And they cope well with being short options for which they have received no premiums. Perhaps most impressively, they can operate adeptly on both sides of a market at once. But none of that explains why we need "quote" messages per se.
Note that at root, the authors discuss protocols - protocols for trading, matching, clearing markets, and such. And that is what we are discussing. But in *their* semantics, whether an expressed willingness to trade on definite terms is a "quote" or an "order" depends solely on the supposed motivations and market roles of the people involved. If they are investors making long-term portfolio decisions, then their expressions of willingness to trade are "orders." "Quotes" are submitted by brokers or dealers acting solely as intermediaries. That distinction is tenuous at best, and what relevance it holds for our task is dubious.
If market centers wish to handle expressions of willingness to trade differently depending upon the source, we don't need two message types to facilitate that. They can treat messages from "Bob" one way and from "Sally" another.
If we wind up with quote messages and order messages, it won't be a tragedy - far from it - but it would be great if you could articulate at your point of concern - the API - how the segregation would help. What information could you more efficiently extract or convey from a "quote" than from an "order," or at least from having that distinction available?
Best,
John
> Please refer to Equity Markets in Action for a discussion on the differences between quote driven and order driven markets. http://tinyurl.com/5vlwuk5 for an understanding of the differences between quotes and orders. While tradeable quotes can be deemed a subclass or a type of order, I remain unconvinced that the distinction should be lost at the API level.
>
>
> > Thank you, Hanno - terrific post. Please see my comments in-line.
> >
> > > I agree with the basic notion that tradable quotes are no different from orders and it makes sense to take a step back and analyse what is needed. Quotes are needed as a concept for private quote negotiations where the indicative character dominates. That is also the reason why you find quote messages in FIX in the section "Pre-Trade" and order messages in the section "Trade".
> >
> > I am arguing in part that the notion of a "tradable quote" is a redundancy; that of an "indicative quote" an oxymoron. A (real) Quote is a species of the genus Order. Like an order, a quote is always executable. As opposed to other orders, the distinguishing hallmarks of a quote are (1) a quote is always disclosed, even if to just one other person, (2) a quote invites orders against it, which will always result in an execution if the contra-order meets the terms of the quote, (3) a quote explicitly or implicitly bears all of the information necessary to the consummation of an agreement, and (4) a quote has a time to live, even if good until cancelled.
> >
> > I am further arguing that in an electronic trading framework, merely as a simplification and to avoid ambiguity, confusion, and the need for a larger dictionary, we can productively dispense with the term "quote" (though not with the functionality quotes provide). That is, we can simplify the semantics of the new protocol and allow orders (and features thereof) to carry the water for quotes.
> >
> > Note that in the negotiated markets to which you refer, a "request for quote" ("RFQ") precedes a quote. In electronic systems, RFQs commonly respond to, and may be shaped by, "indications," which are expressly understood to be informative only and not executable. Note, too, that as a general proposition, I favor richness of language and like that we have a term "quote" that is distinct from the term "order." I just do not see any benefit from embedding that richness of language in an electronic trading protocol seeking to be as efficient as possible, though am happy to be persuaded otherwise.
> >
> > > From an efficiency point of view, quotes are a lightweight version of orders when it comes to automated matching on an exchange system. This is due to the availability of a MassQuote message that carries little baggage and allows the recipient to do parallel processing, especially if quote sets are being used.
> >
> > Yes, agreed, and I appreciate the benefits of merely "updating quotes" as opposed to engaging in mass, cancel-and-replace activity. I wholeheartedly support the concept of enabling market participants to maintain concurrently multiple order positions against the market, amending particular details of those positions as necessary. I do believe that assumptions as to efficiency should be tested. Is there a limit beyond which a bulk position update becomes relatively inefficient, whether because of CPU, network, or other constraints? I don't know, but would be pleased to learn.
> >
> > > I am not convinced we should get rid of quotes all together and only use orders. Orders can carry many different attributes that request a certain behaviour to be followed by the recipient. Most of this "baggage" is not available for quotes and for good reason. A recent Extension Pack from Nordic Growth Markets has added the ability to prevent overfilled quotes by adding two additional quantity fields to the MassQuote that, when used, behave the same way as OrderQty does for orders (total quantity/size). However, the Global Technical Committee has expressly stayed away from adding a quote status model similar to order states and confirmed the prevailing model of quotes being continuously overwritten regardless of the previously executed quantity.
> >
> > Fair enough. While most of the discussion thus far has focused on the needs of so-called high-frequency traders, in my experience another class of market participant deserves our attention just as much: electronic market makers, especially in exchange-traded derivatives and fixed income markets (for which the quote-update intensity is comparable to that manifest in exchange-traded-options markets). I do believe that from efficiency and beneficial-liquidity-provision standpoints, these market makers would benefit from flow control and similar mechanisms (hidden reserves, automated quote replenishment, etc.). We can address these matters more fully in due course.
> >
> > > It might make sense to add a MassOrder message that is different from NewOrderList in that it does not have all the bells and whistles that are normally available to orders. Note that MassQuote is New/Replace/Cancel in a single message and MassQuoteAck is like a MassExecutionReport with the exception of fills still having to go through individual standard ExecutionReports (one by one). I support the concept of a QuoteExecutionReport (or MassExecutionReport) where you get all fills caused by a single MassQuote (or MassOrder) when it hits the matching engine in a single message (atomic transaction). ERs already allow multiple fills in a single message but they all have to be for the same instrument. A structural change of the existing ER is not an option.
> >
> > Strikes me as a good idea.
> >
> > > A word of caution on mass messages. It increases the complexity for the recipient if the constituents of the message cross independent partitions of the matching architecture. It is less efficient if the recipient has to start pulling apart a request at the gateway level and forward partial requests to different partitions. You end up with multiple responses that the gateway either has to consolidate (creating delays) or burden the submitter with. Therefore, MassQuotes are typically limited to the series of a single product and apply to derivatives more than to equities. A MassOrder might look great when trading baskets of some blue chip index but highly liquid instruments tend to be run with parallel matching engines, possibly on separate machines, that do not talk to each other for performance reasons. I can rely on the recipient running the series of a derivative product in a single matcher in order to efficiently support multi-leg orders. I cannot rely on certain equities running together in a single matcher as the grouping might change on a daily basis as volumes change.
> >
> > Thank you - makes sense.
> >
> > > The existing FIX message NewOrderList batches orders together and you can add a ListID to always show which orders belong together. But the orders in such a list are individual entities once they hit the receiving system. I can only cancel a list but have to use one message per order to modify orders in the list.
> >
> > Thanks.
> >
> > > The discussion on this topic is very important but should keep in mind how new stuff can co-exist with existing stuff. Adoption of FIX 5 has been very slow even though it is an incremental change and has been officially out there since December 2006. I do not want to create the notion that people must throw away whatever they have in place for FIX today and start from scratch if they want to switch to a high performance version of FIX. Transport and syntax have a problem in FIX, semantics do not, with the exception of message verbosity which has been addressed in parts, starting with FIX 5.
> >
> > I completely agree and think this is a vital point to keep in mind. It makes great sense to me to begin work on a new protocol from a clean sheet - so much has changed since FIX was conceived, among other reasons. But this effort should not be viewed as a denigration of or threat to investments in FIX as it exists today. Embedded in FIX is an invaluable amount of business knowledge and wisdom that will hopefully never be lost.
> >
> > > Regards,
> > > Hanno.
> > >
> > > > Thank you, Don. Let me respond in order to each of your well-taken points:
> > > >
> > > > > There still is a distinction between orders and quotes in many markets.
> > > >
> > > > Yes, agreed, but this distinction illustrates the vital need for a vigorous, philosophical discussion early in the development of the new protocol: to what extent will it follow legacy market practices and frameworks as opposed to leading and encouraging the development of new, beneficial practices and frameworks?
> > > >
> > > > Functionally, orders and quotes are the same. Each represents an express willingness to enter into a contract (a "trade") on definite terms. When markets impose two-sided-quoting obligations on market makers, in effect they are obligating market makers to maintain orders (meeting certain parameters) on both sides of a market.
> > > >
> > > > Accordingly, in the new protocol, we could dispense with "quote" messages and just have "order" messages, thereby reducing complexity (which in turn promotes adoption). Markets that impose two-sided-quote obligations on market makers could easily test whether their market makers are maintaining orders on both sides of the market that are consistent with their obligations as market makers. Order messages can be equipped with all of the hooks necessary for exchanges to test compliance.
> > > >
> > > > > quoting is usually associated with a market maker role, and market makers are often obligated to enter two-sided quotes.
> > > >
> > > > Also agreed, but a healthy market encourages the provision of standing bids and offers at multiple price points from multiple market participants and thus "quotes" - even if one-sided - from everyone. To prevent free-riding or for other business reasons, some markets prevent participants other than approved market makers from maintaining orders (or "quotes") on both sides of a market at once, but this condition, too, could be tested easily by markets if only order messages were supported in the new protocol. As discussed above, dispensing with quote messages (as distinct from order messages) would not harm the ability of exchanges to enforce two-sided-quote obligations.
> > > >
> > > > > a market maker typically makes only one public quote per instrument and quotes are implicitly cancel/replaced by market maker / instrument / side combination.
> > > >
> > > > Yes, but this can be accomplished efficiently with order messages alone, in combination order-amendment and bulk-order-update capabilities.
> > > >
> > > > > The high frequency trading scenario is a little different. First, a trader may or may not have an official market maker role. Second, a trader may wish to enter numerous orders for the same instrument at different prices, based on a strategy or price laddering, as opposed to one quote for many instruments represented in MassQuote.
> > > >
> > > > Agreed. I have argued elsewhere that I hope we move past the notion - as soon as possible - that this new protocol is for high-frequency traders (whatever that term means) alone - let's have a more efficient protocol for everyone. And, instead of MassQuote messages, we can have "BulkOrder" messages, or something to that effect.
> > > >
> > > > It is time to deprecate the arbitrary distinction between quotes and orders, and this new protocol effort provides the opportunity to do so, without stranding anyone's existing investment.
@FIXProtocol
