A ticker plant is the system that takes raw market data feeds from exchanges, normalises them into one consistent format, rebuilds the order book from the message stream, and delivers the result to trading applications with as little delay as possible. Every firm consuming direct exchange feeds runs one, whether built in-house or bought.
Why raw feeds cannot be used directly
Each venue publishes in its own protocol, with its own sequencing, recovery and book-building rules. A firm connected to thirty venues would otherwise need thirty parsers, thirty recovery implementations and thirty sets of edge cases to maintain, all of which change whenever a venue changes its specification.
Normalisation collapses that into one interface. The cost is that the normalising layer is now on the critical path, so its latency becomes the firm's latency.
What a ticker plant actually does
Four things, in order. It decodes the venue protocol. It handles gaps, retransmissions and the recovery sequence when messages are missed. It maintains book state, applying each update to the correct price level. And it publishes the result to downstream consumers, usually through shared memory or multicast for local clients.
Where the latency goes
Most of the delay in a ticker plant is not parsing but book maintenance and the handoff to consumers. A full-depth book under heavy load involves far more work per message than decoding it, which is why throughput under burst conditions matters more than headline latency on a quiet feed. Measuring the plant with a steady synthetic stream flatters it; measuring it at the open does not.
Build or buy
Building one is a serious commitment: the hard part is not the first venue but the twentieth, and the ongoing obligation to track every specification change across every market. Commercial plants exist to absorb that. InRush Ticker Plant is Pico's, and RedlineFeed consolidates direct feeds from 230+ venues into a single normalised stream for firms that would rather not run the connectivity themselves.
