Xignite APIs are used by many of our clients in trading environments. By its very nature, trading imposes a more drastic set of requirements upon market data solutions. Traditionally, trading applications have relied on expensive and complex continuous feeds–as they were the only technology available to support such requirements. But REST APIs have improved dramatically in the last few years, in their scalability, reliability, latency, and performance and Xignite has been leading the pack in all categories. Today, many firms building trading capabilities from scratch are bypassing continuous feed entirely and building their tech stack entirely on REST APIs. This way they can avoid complex development cycles and infrastructure fees–all the while providing their customers with a high quality experience. 

The challenge is that if the latency of an API is too high, or if the data is delayed or inaccurate in any way, then the likelihood of a trade not executing increases dramatically–and this is never good. For agency trades for instance, Rule 603 Regulation NMS requires brokers to comply with the Vendor Display Rule. This means that the broker must display an accurate NBBO to their customers, who then decide at what price to trade at or whether or not to place a market or limit order. Not displaying the NBBO or displaying a stale NBBO is likely to land the broker in hot water with traders and regulators alike. In other cases, brokers may be executing trades in their Principal capacity, which means that they are buying and selling securities directly from their own inventory. In this case, FINRA is very strict about such trades executing within the NBBO. Trades falling out of that range are likely to be flagged–resulting in potential financial losses and regulatory scrutiny.

Given this context, it is critical that quotes served by REST APIs be as up-to-date as possible–or have the lowest latency possible. Sub-second latency is a must have but generally speaking, while ultra low latency (sub millisecond) could be an overkill in a non-machine trading environment, latency under 200ms is preferred. Note that by latency we mean the total latency from the time the exchange issued and timestamped the quotes (each of the legs of the NBBO), to the time it is displayed to the user. Given the many steps, networks, and applications involved in conveying this information, this is a complex endeavor indeed.

To further address this requirement, Xignite has decreased the caching rate of data on the XigniteGlobalRealTime API (the API you would use to get the NBBO) by 50%. This enhancement was deployed early September 2022 and is already available to all clients. We have since been observing around 35% increase in quote updates due to increase the update frequency in peak time. We have also noticed significant reductions in the frequency of upstream delays. And our clients executing Principal trades have been delighted with the results.

For those who wonder why Xignite is caching/conflating those quotes in the first place, understand that XigniteGlobalRealTime API is one of our most popular APIs. It serves approximately 22 billion API requests per month–which means a peak activity at market open or close–well over 50,000 API requests per second. To support such levels of activity, some level of caching is required.

Note that most of our APIs still display second-level timestamps so it is hard to appreciate those improvements with the naked eye. We will soon be introducing milliseconds precision on those APIs.