The Next Generation Exchange (in Space)

It is interesting to consider what the next generation of exchanges might look like.? The exchanges we have today work both efficiently and robustly, so why do we even need a TNG Exchange? For the purposes of this thought experiment I have presumed that someone wants to build an exchange that operates in Low Earth Orbit aboard StarLink satellites, but this is just a device to explain just why I think the legacy exchanges need to be reimagined as TNG exchanges in the first place.? My intent is to make you rethink the premises behind what we have today and to have a little fun considering what we might build for the future.? Let’s see where a clean sheet design might lead.

Any design of an exchange must start with the goals it will satisfy: we start by asking, what is it that this new design is trying to achieve?? Our TNG Exchange is still an exchange, which means it will start with the requirements shared by the existing exchanges: efficiency and robustness.? But to be worthy of the moniker TNG, I am adding three more requirements:?

• it must operate 24 hours a day, every day of the year;
• It must handle 100,000 clients simultaneously trading the same instruments;
• It must accomplish all of the exchange goals with equal fairness for all clients–a level playing field for the largest banks, the biggest hedge funds and the smallest retail investors who trade programmatically.

I hope during this short paper it will become fairly obvious why I selected these particular goals, but let’s start by discussing them briefly and directly.? As trading becomes truly global, there is no reason to stop trading, ever, even for a daily reset.? On the technical side, we know how to build systems that run continuously without noticeable disruption.? On the trading side, if there is poor liquidity during certain hours, clients of the system can choose to come back when conditions improve, but the system is always available.

While 100,000 simultaneous clients is a lot, if the TNG Exchange is going to serve retail customers as well, this number may not be large enough.? It will, however, suit today’s discussion, as a starting point for this discussion, which is the same as writing an article about creating an exchange in space.

Fairness–which includes transparency of the order, price and execution methods and routes–is something we already hear regulators and legislatures discussing and customers complaining about.? If the TNG Exchange fails to provide at least a semblance of fairness to all clients, it will fail–and it should fail–to be adopted by potential customers,? so long as they are free to choose when and where to trade or not to trade.

These are, admittedly, audacious goals; but I think they are worthy of our consideration.? Given these goals, what are the problems we face?

To be robust, to handle failover, to run every hour of every day all year long, to be able to periodically recycle the parts of the exchange system, and to provide upgrades as needed, a well understood and well tested, three server, hot-hot-cold design is needed.? Hot-hot-cold design deserves its own separate article, but let me outline it briefly here.? The first hot server is the active trading server.? The second hot server is active and executing all of the trading, but its outputs are not sent to participants but captured for live comparison with the active trading server.? If and when the first server fails, the second server takes over trading without significant delay.? The third server is not normally active but being sitting cold for upgrades, beta testing and anything else that can be interrupted at a moment’s notice.? If the first or second server fails, the third server becomes active as the secondary hot server while the failed server is repaired.? While a hot-hot-cold system requires sufficient time to design, build and test it prior to operation, if the TNG Exchange is conceived as this type from the beginning, this challenge is an implementation detail rather than something entirely new and novel: efficiency and robustness can be even better than what the legacy exchanges provide.

What is new is the size, scale and distribution of the TNG Exchange because it is located across multiple satellites operating in space.? Because the satellites are in motion over the ground, the latency from the ground up to the hot matching engines is deterministic, but variable, depending on where the satellites are in the orbit and how far the closest satellite is to the ground station you are using.? Unless the TNG Exchange design is adequate, the largest trading companies will figure out ways to game that latency to their advantage, ending the fairness we require even before we get off the ground.

To deal with the fairness issue we need to understand just how bad the problem is.? What are the best and worst-case latencies?? A quick estimation can answer that question.? The combined radius of the Earth and the satellites orbiting above it is a little less than 7,000 km.? That means the on-orbit distance halfway around is just under 22,000 km.? This gives a worst-case latency from any ground station up to the matching engine of just less than 75 ms if the satellite with the hot matching engine is currently halfway around the Earth and less than 5 ms if the satellite is right overhead.

I am picking 25 ms–or a third of the way around the world using cabled transmission lines–as the one-way latency from the server used by a retail investor to a ground station.? You can argue with that number but it does not change the results of my analysis much, so grant me this number for now, purely for the purposes of this discussion.

This totals up to a round trip latency of 55 to 205 ms, with more than a millisecond to run a brief analysis and decide if there is a new or adjusted order or cancel to be sent or not: something current, widely available servers can do.? Hold on to those numbers while we consider another limitation of building a TNG exchange in space.

No matter how good the ground stations and satellites are, bandwidth is always limited.? With 100,000 or more customers simultaneously sending and receiving messages, at some point any bandwidth limit is going to be exceeded.? A lot can be done to alleviate the problem if we limit the size of the messages and maybe we even compress and combine the messages, but still we design the exchange knowing that bandwidth will be a limiting factor in the trading our customers want to do: if not today, then someday soon.? What customers need is–somehow–to trade without falling behind either in the sending or receiving of messages.? Especially considering the latency, how does a TNG Exchange provide this level of fair access while maintaining the required efficiency and correctness of operation?

While we ponder that question, we cannot forget that if we are going to provide fair access to retail investors, the TNG Exchange must be simple to understand and use based on well established principles of trading and of coding.? It must be straight-forward to implement a basic trading system for a retail client with some programming experience and the system must be absolutely transparent in how it works.? How orders get to the matching engine; how the matching engine operates; how the pricing engine gets its information from the matching engine and how it distributes prices; how the matching engine returns private information to each client, including the sequence in which all this information is distributed, all of this must be transparent and easy to grasp.? And this list is just for normal operations but the design must also include handling for the various failures and fail-overs that will likely happen during the life of the TNG Exchange: asteroids are suddenly a relevant concern.

If I have done a good job up to this point at laying out the problems–admittedly, only in outline form–then there are any number of solutions you are now likely to be considering as to how a TNG Exchange might meet the lofty goals we started with.? Different exchanges and dark pools trading different products with different levels of regulatory oversight will all need slightly different designs for their version of a TNG Exchange.? What I am looking for by writing this article and asking all of these questions is that you might come up with some interesting ideas on how to best build a TNG Exchange.? Having brought us this far, I would be a poor host if I did not now disclose my favorite solution for a TNG Exchange in Space.

To keep my solution simple I want to use tried and true market mechanisms with slight variations that accomplish everything I set out to achieve.? While my combination of tweaks to existing platforms is perhaps different from those you have heard before, none of the components are new to any of us.

I like a TNG Exchange that uses nano-auctions and pro-rata, fractional fills.? For a system with less than 250 ms round trip latency for all participants, there would be 4 auctions per second: if the latency is less, the number of auctions could be proportionally higher.??

The matching engine sits in space collecting orders and updates of all types–hereafter just called “orders”–for 250 ms.? During this period the pricing engine is told nothing about these orders.? Then the doors inside the matching engine close and it trades any crossing orders and updates its internal books with the remaining non-crossing updates.? During this time the matching engine holds any orders arriving, to be processed during the next auction.? When the matching engine updates are complete the doors open, public information is sent to the pricing server and then to the customers, private information is sent directly to the affected customers and the matching engine again collects orders until the 250 ms clock expires and the doors close again.

To stay within the bandwidth limitations of the system, each customer will be allocated just three orders they can send per instrument per auction: one resting bid or cancel all bids; one resting offer or cancel all offers; one aggressing order. ? If the bandwidth of the system allows it, given the current customer base, the operator of the exchange could multiply the three orders per auction per customer by a factor for all customers, picking a number that uses up most of the available bandwidth without overloading any retail client using a commonly available server.? If customers are added more quickly than bandwidth is, the factor used would be reduced to ensure customers and the network were never overwhelmed.? Even a factor of one, which limits each customer to a single order of each type per instrument per auction, is a capacity around which real and profitable systems can be built.

This is my favored solution: what is yours?? Do you see any other goals the legacy exchanges would do well to handle?? Please leave your thoughts in the comments below.

There are many follow-on issues and discussions that can use this article as a starting point.? For instance: what state needs to pass between auctions; aren’t there a few different ways that resting, unfilled orders can be handled; what are useful reliability requirements that can be captured early on; what regulatory and legal hurdles are there for a TNG Exchange to overcome?? Perhaps you know some additional issues that need to be discussed.??

Thank you for your time.