Update: OPRA Message Change Prompts Bandwidth Increases

Although consumer firms have been advised by OPRA to ignore the field, vendors who must redistribute the OPRA feed including the new header format say that regardless of whether firms can utilize the expanded data, it still incurs a greater delivery burden.

The old message header format included a participant ID, a message category field, a message type field, and a message indicator field, each accounting for one byte. The header now includes a new, eight-byte transaction ID field, bringing the new total size for each OPRA message header to 12 bytes.

"Bandwidth costs money, but if you're receiving twice the amount of data, you need twice the amount of hardware and software, and one of the trends at the moment among our clients is infrastructure consolidation-clients looking for us to take over their infrastructure burden," says Ian McIntyre, European chief operating officer of low-latency data platform and feed handler provider SR Labs. "Every time there's a step-change, there is more bandwidth, hardware and software to be bought... and it's a drain on clients."

A spokesperson for low-latency ticker plant and enterprise datafeed vendor Activ Financial says the vendor is "fully supporting" the new header. "The most significant impact was on bandwidth required for receiving OPRA data because it expanded the message size by nearly 30 percent. [But] being that we have 40 Gigabit-per-second circuits in place for processing OPRA, our capacity is sufficient," Activ officials say.

"We provide real-time utilization updates to clients... and we did some infrastructure upgrades prior to this change, so it's not a big scramble for us. And there are actually some consistency and validation checks that we perform," says Daniel Bartucci, infrastructure product manager at Pico Quantitative Trading.

Prior to going live with the new format on Monday─which will be supported alongside the old format until March 18 in case of any need for OPRA to fall back to the old version─OPRA conducted a final test session with industry participants on Saturday, Feb. 27, where it tested the new data format in different scenarios, and simulated a fall back to the old message header format.

"In summary, the preparations and handling of the Exchange-Driven Change (EDC) for the OPRA feed were smooth and successful for Exegy and our customers," says David Taylor, chief technology officer at hardware appliance-based data platform and feed handler provider Exegy. "To minimize operational risk on behalf of our customers, we chose to implement forward- and backward-compatible changes in our OPRA feed handler. This not only aided in early deployment of the updated feed handler for testing and production hardening, but it also provided an automated way to handle conditions where OPRA chose to roll back to the prior format (a right that they reserved in the event of technical issues with the new format). We released these updates to our OPRA feed handler over five months ago. This enabled us to build significant confidence by supporting early acceptance tests by our customers and participating in multiple rounds of industry-wide testing on weekends."

McIntyre says the extended header has represented an opportunity for SR Labs to leverage its Filtered Options Feed service as a means to help clients reduce their bandwidth utilization─depending on their particular use case─by up to 75 percent.

Because FOF publishes data in the same raw data feed format used by OPRA, clients could easily move from the full-bandwidth feed to the lower-bandwidth filtered feed without needing to change formats or feed handlers, and which also allows them to conflate data to only four updates per second, depending on clients' needs, he says.

Taylor says the change also represents an opportunity for Exegy to mitigate clients' operational risk associated with implementing the new field. Exegy still ingests the high-capacity OPRA feed into its datacenter, then provides a range of flexible options for how clients can consume the data-either filtering it where needed, or storing every tick for historical analysis.

However, it also "probably spurs another opportunity on the client side to evaluate how to manage your bandwidth and feeds," Bartucci says, warning that while Pico also employs 40 Gbps networks to connect to exchanges, handling the additional data effectively isn't just about having the biggest telecom pipes.. "But if you haven't maximized your throughput models, all the bandwidth in the world won't help you."