Request for Comment: Lightweight Order Message

, ,
1

Imported from previous forum

2

[ original email was from John Harris - john.harris@bondmart.com ]
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.

3

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.

4

[ original email was from John Harris - john.harris@bondmart.com ]
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.

5

You violate protocol layers, adding cost that is perhaps measured in billions per year, without adding any significant benefits processing wise.
The receiving end will need to demultiplex, adding a cost that is likely higher than the savings in processing the fields that you eliminated.
If you want to save bytes on the wire, you can do that to some extent without mixing the layers.

Anders

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.

6

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

Thank you for this comment.

May I trouble you to explain how this “violate(s) protocol layers?” Do you means FIX Protocol layers (i.e., session versus application) or something else?

Also, sorry, I do not understand your “demultiplex” point and would appreciate learning from you on that score. I do have a general understanding of multiplexing, so you needn’t go into too much detail.

Thank you.

Best,
John

You violate protocol layers, adding cost that is perhaps measured in billions per year, without adding any significant benefits processing wise.
The receiving end will need to demultiplex, adding a cost that is likely higher than the savings in processing the fields that you eliminated.
If you want to save bytes on the wire, you can do that to some extent without mixing the layers.

Anders

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.

7

John,

I mean in the traditional sense of protocol layering (google for “protocol layering benefits” or similar). There are situations where mixing layers to gain performance makes sense, but in this case you are suggesting that about 32 bits worth of information is saved and it does not seem that you have exhausted other means for saving that data on the wire (just use FAST).
On demultiplexing, this obviously will not be practical to apply over TCP. Using UDP, you will consume resources by mapping from a port to the receiver of that data. The cost of that is likely at least as high as the cost of dispatching based on having the information in the message itself.
I think that to justify this you need to try to quantify the net savings of the approach, and preferably implement and get some hard numbers from benchmarking in relevant environments. Philip listed the downsides and at least some back of the envelope calculations need to be done to evaluate the advantages.

Anders

Anders,

Thank you for this comment.

May I trouble you to explain how this “violate(s) protocol layers?” Do you means FIX Protocol layers (i.e., session versus application) or something else?

Also, sorry, I do not understand your “demultiplex” point and would appreciate learning from you on that score. I do have a general understanding of multiplexing, so you needn’t go into too much detail.

Thank you.

Best,
John

You violate protocol layers, adding cost that is perhaps measured in billions per year, without adding any significant benefits processing wise.
The receiving end will need to demultiplex, adding a cost that is likely higher than the savings in processing the fields that you eliminated.
If you want to save bytes on the wire, you can do that to some extent without mixing the layers.

Anders

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.

8

[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, sir - duly noted.

John,

I mean in the traditional sense of protocol layering (google for “protocol layering benefits” or similar). There are situations where mixing layers to gain performance makes sense, but in this case you are suggesting that about 32 bits worth of information is saved and it does not seem that you have exhausted other means for saving that data on the wire (just use FAST).
On demultiplexing, this obviously will not be practical to apply over TCP. Using UDP, you will consume resources by mapping from a port to the receiver of that data. The cost of that is likely at least as high as the cost of dispatching based on having the information in the message itself.
I think that to justify this you need to try to quantify the net savings of the approach, and preferably implement and get some hard numbers from benchmarking in relevant environments. Philip listed the downsides and at least some back of the envelope calculations need to be done to evaluate the advantages.

Anders

Anders,

Thank you for this comment.

May I trouble you to explain how this “violate(s) protocol layers?” Do you means FIX Protocol layers (i.e., session versus application) or something else?

Also, sorry, I do not understand your “demultiplex” point and would appreciate learning from you on that score. I do have a general understanding of multiplexing, so you needn’t go into too much detail.

Thank you.

Best,
John

You violate protocol layers, adding cost that is perhaps measured in billions per year, without adding any significant benefits processing wise.
The receiving end will need to demultiplex, adding a cost that is likely higher than the savings in processing the fields that you eliminated.
If you want to save bytes on the wire, you can do that to some extent without mixing the layers.

Anders

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.

9

So just to be clear, if the exchange is using TCP/IP, the destination address and port should uniquely identify the stock? And in your earlier mobile phone example, the stock is uniquely identified by the phone number I SMS the instruction to?

If this is the proposal, there are of course lots of detailed technical reasons why it’s inconvenient to implement - for example, in the TCP/IP case you’ll need thousands of connections open, which means thousands of logon sequences, heartbeats and sessions to recover in the event of failure. Furthermore, counterparties typically like to open up the minimum number of addresses and ports for a single logical flow - i.e. preferably 1 - both for security and ease of administration. A derivatives market will need to support hundreds of thousands of address/port combinations, with new ones being added every month.

However, even if these could be brushed aside, debugging any sort of issue in such a system would be hellish - it would be very difficult to work out which stock an order was actually for. And debugging it would be a regular occurrence, as use of the wrong connection would probably be frequent (it’s hard to turn AAPL into INTC by mistake, but easy to turn port 53857 into 53758 or 53856) and would typically involve some sort of financial loss (by trading at an inappropriate price). One of the reasons counterparties often duplicate stock codes in FIX is to lessen the chances of this kind of confusion.

I think getting rid of stock codes is a very marginal saving and is massively outweighed by the risk and inconvenience such a step entails.

10

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

We could add to that list “buy to open,” “buy to close,” “sell to open,” and “sell to close.” But let us acknowledge that not all markets need all such constructs. We have no “sell short” orders in the bond market. We do sell short, but we do not mark our orders that way.

Best,
John

Chaps,

You can’t lose side either. It’s tempting to think of + as buys and - as sells, but what about short sells?

Jim.

So just to be clear, if the exchange is using TCP/IP, the destination address and port should uniquely identify the stock? And in your earlier mobile phone example, the stock is uniquely identified by the phone number I SMS the instruction to?

If this is the proposal, there are of course lots of detailed technical reasons why it’s inconvenient to implement - for example, in the TCP/IP case you’ll need thousands of connections open, which means thousands of logon sequences, heartbeats and sessions to recover in the event of failure. Furthermore, counterparties typically like to open up the minimum number of addresses and ports for a single logical flow - i.e. preferably 1 - both for security and ease of administration. A derivatives market will need to support hundreds of thousands of address/port combinations, with new ones being added every month.

However, even if these could be brushed aside, debugging any sort of issue in such a system would be hellish - it would be very difficult to work out which stock an order was actually for. And debugging it would be a regular occurrence, as use of the wrong connection would probably be frequent (it’s hard to turn AAPL into INTC by mistake, but easy to turn port 53857 into 53758 or 53856) and would typically involve some sort of financial loss (by trading at an inappropriate price). One of the reasons counterparties often duplicate stock codes in FIX is to lessen the chances of this kind of confusion.

I think getting rid of stock codes is a very marginal saving and is massively outweighed by the risk and inconvenience such a step entails.

11

[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Philip. Please see my comments in-line:

So just to be clear, if the exchange is using TCP/IP, the destination address and port should uniquely identify the stock? And in your earlier mobile phone example, the stock is uniquely identified by the phone number I SMS the instruction to?

I suggested only that the destination address be unique as to instrument and side (in order to support the most efficient order messages conceivably useful). Yes, a unique IP address and port would be one possible proxy for such an arrangement. My mobile phone example did not assume this scheme - I specified both instrument and side in that example. I take your point, however. A given phone number, used as an order destination address, could also represent a unique instrument and side.

If this is the proposal, there are of course lots of detailed technical reasons why it’s inconvenient to implement - for example, in the TCP/IP case you’ll need thousands of connections open, which means thousands of logon sequences, heartbeats and sessions to recover in the event of failure. Furthermore, counterparties typically like to open up the minimum number of addresses and ports for a single logical flow - i.e. preferably 1 - both for security and ease of administration. A derivatives market will need to support hundreds of thousands of address/port combinations, with new ones being added every month.

This is not THE proposal - it is not even formally a proposal. I posited the least verbose message I could conceive as useful, under narrowly constrained (but technologically feasible) conditions. But I will respectfully challenge your assumptions in return. Globally, virtually all trading volume in dollar terms is concentrated in a relative handful of instruments. Daily trading in five, benchmark U.S. Treasury issues dwarfs the dollar volume of all U.S. stocks trading on all exchanges. If memory serves, shares of beneficial interest in a single ETF may account for ten percent or more of the daily trading volume in U.S. stock markets. It isn’t necessary for exchanges to trade thousands of goods in order to be successful - they can be incredibly successful running just a dozen order books. Neither would it be necessary for all exchanges to facilitate such lightweight messages or, within exchanges, for each of their order books to accommodate such messages.

If we include all securities, commodities, and contracts in our analysis, millions of instruments are traded on a global basis. Of these, only a small fraction are traded on exchanges and subjected to a matching process. Of those, only a fraction see any significant volume on a daily basis. In designing this new protocol, I submit we will discover that trying to design a single order-handling protocol or order message is less than optimal in relation to the actual business requirements.

However, even if these could be brushed aside, debugging any sort of issue in such a system would be hellish - it would be very difficult to work out which stock an order was actually for. And debugging it would be a regular occurrence, as use of the wrong connection would probably be frequent (it’s hard to turn AAPL into INTC by mistake, but easy to turn port 53857 into 53758 or 53856) and would typically involve some sort of financial loss (by trading at an inappropriate price). One of the reasons counterparties often duplicate stock codes in FIX is to lessen the chances of this kind of confusion.

Respectfully, I believe that this objection conflates what the sending application needs to do and “know” with what the message must contain. Between the application (with all of its associated libraries and data stores) and an operating system, provision can be made for reliable, accurate addressing.

I think getting rid of stock codes is a very marginal saving and is massively outweighed by the risk and inconvenience such a step entails.

Perhaps so, but that assumption needs to be tested just as rigorously as my assumption that we can beneficially do without such information in some order messages under some circumstances. More generally, we have to create a framework for assessing “efficiency” (or “high performance”) that takes into account as fully as possible as resource requirements, including those you have wisely and appropriately raised here.

12

John,

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

An interesting idea, although I have to agree with the technical objections
raised by others in this forum.

Any thoughts on how this ties in with your ideas on mandatory identification of
roles (principals and agents) and requiring order allocation?

Also, how do you see orders involving multiple instruments being handled
in this scenario?

Best regards,

/Peter

13

[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Peter. The technical objections are appreciated, too :slight_smile: Comments below:

Any thoughts on how this ties in with your ideas on mandatory identification of roles (principals and agents) and requiring order allocation?

Under this lightweight order scenario, the exchange infers the identity of the sender from his physical connection to the exchange. Let’s assume that the exchange has assigned a numeric identifier to the sender of 123456789 (the “SenderID”). That SenderID is associated with a given port on a switch to which that sender is connected. In the exchange’s database, that Sender ID could be mapped to any number of fixed, agent/principal relationships (agent representing single principal, agent representing multiple principals with standing allocation instructions, or principal only). I cannot conceive of this scheme working for dynamic agent/principal relations or allocations, however - only static relations (though these could be updated out of band). I see this type of order working best for a single principal, a single agent/principal relation (e.g., the legally-distinct manager of a single investment company), or a single agent manager of a small number of affiliated investment companies (e.g., the legally-distinct manager of an offshore/onshore complex of funds that are always traded in tandem). I do not see it working for the classic, separate-accounts manager who trades in blocks for dozens of hundreds of accounts at once, with the exact mix of accounts and quantity allocations changing from one trade to another.

Also, how do you see orders involving multiple instruments being handled in this scenario?

This would easily work for scenarios in which multiple instruments trade in a single book (e.g., for swaps or butterflies in debt markets). The connotation of “sell” and “buy” would be defined in advance by the exchange and sensible in light of the instrument definition. For example, “selling” a 2/5/10 butterfly would be defined as selling the 5YR and buying the 2YR and 10Y on a pre-defined, duration-weighted basis. In that case, the response messages from the exchange would be more complicated than I set forth in my example, but eminently feasible. I do not see it working as simply as I have outlined for lists in which the constituents would be executed in distinct books, because separate price specifications would be needed (I think). But, a destination address could be used as a proxy for a pre-defined list of securities (e.g., the constituents of an index). By protocol, the exchange would expect to see price specifications in a particular sequence. This would relieve the inbound message from re-stating all of the involved security IDs. This is actually a really interesting question, however, if we start thinking in terms of price being expressed as a target price or even VWAP or something to that effect.

John,

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

An interesting idea, although I have to agree with the technical objections
raised by others in this forum.

Any thoughts on how this ties in with your ideas on mandatory identification of
roles (principals and agents) and requiring order allocation?

Also, how do you see orders involving multiple instruments being handled
in this scenario?

Best regards,

/Peter