Re: Request for Comment: Lightweight Order Message
John Harris / BondMart Technologies, Inc.
28 Jan 2011 8:13AM ET
Rolf,
Assume I will be sending this lightweight order message to an address that is guaranteed by the exchange to be unique as to instrument and side. Accordingly, by agreement, conveying instrument ID and side down the wire is unnecessary. The receiver presumes all messages arriving at that address are, e.g., buy orders for common shares of XYZ. Further, assume I am sending this message from a general-purpose computer with an operating system that knows how to send messages to that unique exchange address, formatted in a manner that is protocol compliant. My application is presumably aware of instrument ID and side and knows how to communicate with the OS in a way that the OS requires in order to render its service in this transaction, but the order message that goes down the wire needn't contain that information - by prior agreement.
This hypothetical deliberately challenges conventional notions about trade messaging. But the concept has a proven, physical-world analogy and is consistent with the idea of creating the most efficient messages.
If I am trading in a pit for a given commodity or at a post for a given stock, it isn't necessary for me to specify what good I am trading - that information is inferred from my physical presence at that location. My counterparts assume that I did not wander haphazardly into the XYZ pit and begin shouting orders for ABC shares.
Even in a pit, of course, side is not implicit; my posited message goes a step further than physical-world analogies in that respect.
We can all agree that in order for a transaction to occur, the parties have to agree on who is buying, who is selling, what good is the subject of the transaction, etc. In designing a new trading protocol, part of what we must decide is HOW the parties arrive at a shared understanding of the necessary details. That all order messages must explicitly state, e.g., instrument ID or side is not axiomatic. It may be demonstrated, ultimately, that in taking into account everything we know and accounting as best we can for all resources, requiring such details in every message is most efficient. But that has not been demonstrated as yet.
Best,
John
> John, this doesn't make sense to me. How would the instrument id and side be conveyed at "a lower communication layer"? Why would you not want to include the instrument id and side in the message?
>
> Best,
> Rolf
>
> > Request for Comment
> > --------------------
> >
> > I will posit that it is possible for us to create an order message with just three business-application-level fields:
> >
> > -- Order ID
> > -- Quantity
> > -- Price
> >
> > Let us assume for illustration purposes that the destination for this order is an exchange.
> >
> > The following protocol would facilitate such a lightweight order message:
> >
> > 1) The identity of the sender would be inferred from his physical connection to the exchange, e.g., as a node on the exchange LAN or connection to a known port on an exchange switch.
> >
> > 2) At a lower communications level the destination address is specified (having been provided in advance by the exchange). That destination address is unique as to instrument ID, side, and settlement date and location (details of which the sending application could learn via prior query).
> >
> > 3) The response to this message would be an execution report, status report (e.g., "posted to book"), or rejection, each of which could be similarly lightweight.
> >
> > As a general proposition which we can discuss in more detail later, allowing destination addresses to serve as surrogates for instrument identifiers could mean substantial savings for market participants, perhaps measured in billions of dollars per year.
> >
> > Comments appreciated.
@FIXProtocol
