The SEC’s initiative to revamp the National Market System (NMS) data collection and distribution framework is both welcome and overdue (see SEC press release 2020-34). The time has come for firm action, to bring market data collection, distribution and pricing up to speed with today’s technology and practices on both Wall Street and Main Street.
It’s been forty-plus years since the NMS universe was codified into law. To catch up with the market and technological changes that have occurred over that time, significant changes are needed. Last week, Brett Redfearn, the SEC’s director of Trading and Markets, voiced enthusiasm for a single plan that opens up governance, broadens content in feeds, and supports competition among consolidators.
Our work at MayStreet has revealed a set of keen, persistent insights into how the potential new NMS regulations and the supporting security information processor (SIP) infrastructure ought to look like.
To carry us into the next decade while ensuring a level playing field that’s fair and technically smart—regardless of who builds it—the new NMS/SIP universe on day-one should minimally include:
- Retainment of current requirements for raw data submission – At the outset, Self regulatory organizations (SROs) should be able to send data to the SIPs using the same proprietary methods they use today. Retaining these avoids a multi-year re-engineering effort. Eventually, SROs would transition to accessing the same inputs as the current SIP.
- Service indirection – Users should be allowed to request IP/ports for a given service. A primary goal of indirection should be to let services evolve faster with less client impact. The services could wrap different levels of functionality, such as existing SIP and depth, including future functionality such as distributed SIP, snapshots and conflation.
- Output requirements – A simple binary encoding is needed for the SIP output, similar to existing protocols—possibly offering a binary emulation for ease of transition. On day-one, the output should include the current content along with per-symbol status messages, imbalances/auctions and some amount (three levels?) of book depth. The protocol should be level-based (not order-by-order), making the process more resilient and easier to consume.
- Monitoring and performance reporting – To ensure competitiveness, the newly-configured SIPs must meet a set of minimum operating standards. All SIPs must be required to provide detailed, publicly available statistics on message loss, throughput bandwidth and latency. This would prevent SIP consumers from cherry-picking bad SIPs in order to lower execution standards.
- Pricing model and administration – A clear pricing model, clean on-boarding procedures as well as streamlined administration processes should all be mandated. All admin processes should be web-based. Audit rights should also be significantly reduced.
Along with the above minimally required features, to increase the SIPs value over the long term, several additional requirements should be considered for gradual NMS/SIP implementation:
- Distributed model – While necessary, a distributed SIP service implementation is unlikely at the outset because of the inherent complexity of such a massive reconfiguration. However, supporting a level of indirection (see above) allows recipients’ applications to be “future proof” and employ the most efficient network routes available, including wireless.
- Snapshot support – Eventually, users should be allowed to request the state of all open products on service start up. The service should support considerably higher message counts than many existing proprietary feeds, which often limit the number of messages.
- Market by orders – The SIPs ought to ultimately support full depth-of-book data on an order-by-order basis. Currently, order book assembly is difficult for many consumers because it requires receiving all messages without any drops.
- Multiple SLAs – The service level agreement (SLA) configurations supported by the revamped platform must include several levels of data delivery scheduling, including low-latency, delayed, end-of-day, etc.
- API support – Any reconfigured SIP regime must provide pre-built APIs for data interactions initiated in several popular languages, including C++, Java, C# and Python.
- Cloud delivery – SIP data must be readily available to major cloud computing/storage vendors.
- REST/conflation – The functionality should allow users to easily access data subsets.
These measures constitute a set of “minimum specifications” for how a new SIP should be built—regardless of whoever eventually builds it. Together they provide a clear directive of what the SIPs could be in the near future.
Of course, it’s possible to go beyond these guidelines and add functionality to generate even greater value for market participants. Indeed, if these items are considered “table stakes” then competing consolidators will be judged firstly by their ability to meet these criteria and secondly on the collective benefit of their proposed enhancements.
We all know the existing regime is past its expiry date. Data is expensive, growing and constantly changing. At MayStreet, we believe a market-based solution is more agile and capable of delivering a solution that makes tomorrow’s enormous volumes of data usable and digestible.
I hope you find this useful food for thought.
— Patrick Flannery, Co-Founder and CEO, MayStreet
