27The Vendor Map

Eurex’s list of independent software vendors runs to thirty-three companies, each marked by the part of a trading firm it serves: back office, middle office, front office. Its other lists name market data vendors, brokers and sponsored access providers. A new trading firm buys most of its stack, and its first map of the market is a map of vendors: whom it buys colocation from, which ticker plant decodes its feeds, whose servers run its strategies, whose clocks stamp its records.

The earlier chapters met these vendors one product at a time: switches and layer-1 devices in chapter 2, network cards in chapter 3, clocks in chapter 4, capture in chapter 5, FPGA cards in chapters 6 and 7, servers in chapter 8, colocation and routes in chapters 9 to 15. This chapter puts them on one map by category, attaches a firm’s stack to it as a graph, and measures what the map shows: how concentrated the firm’s spend is and which vendors’ failure would stop it trading. Vendors are named only from a venue’s list or their own publications; the example stack is synthetic.

27.1 Market data

A firm can decode each feed inside each strategy (Book 13’s feed handler) or once, centrally, in a ticker plant. Vendors sell both. Exegy describes centralised ticker plants as “the dominant architectural response to the scaling limitations of embedded feed handlers”, and names their cost: “distribution complexity and latency overhead” (Box 27.1). Pico’s product page defines the ticker plant as software that connects to the feeds, normalises the messages and keeps the books in memory, for more than 230 venues. The choice is chapter 1’s multicast question turned into procurement: one decode and a second network, or many decodes and none.

27.2 Execution software and order management

Exchanges publish their certified vendors. Eurex’s list gives each company’s services by office: Trading Technologies for back and front office, Broadridge and OnixS for front office among many others. For a new firm the list is a shopping list and a constraint: a vendor that is not certified for a venue cannot connect the firm to it, and every venue’s certification is a separate project (Book 13).

27.3 Network hardware and servers

The hardware categories are the ones measured in chapters 2 to 8, and each has a handful of vendors that low-latency firms use: a switch vendor for the aggregation layer and a layer-1 device vendor for fan-out; a network card that supports kernel bypass; an FPGA card for the hardware path; overclocked servers. A firm usually standardises on one vendor per category, for spares, skills and drivers; that choice is what makes a vendor a single point of failure, and chapter 28’s recovery plan has to cover it.

27.4 Timing and monitoring

Timing and monitoring are the categories a firm can survive losing for an hour and must not lose for a day. A grandmaster clock feeds every timestamp the regulators ask for (chapter 4); network analytics and capture appliances (chapter 5) see what the firm’s own systems do not. Neither sits on the path from data to orders, so neither stops trading; both stop the firm from proving what it did, which is its own kind of halt.

27.5 Reading the map: lock-in, concentration and exit

A stack is a graph: market data comes in, passes through components, and leaves as orders. Each component is supplied by one or more vendors, or built in house. Two questions follow. Which components, failing alone, cut every path from data to orders? And which vendors, failing, take out every component they alone supply and so cut it?

    def connected(self, removed=()):
        """Is there a path from source to sink avoiding the removed components?"""
        gone = set(removed)
        seen, todo = {self.source}, [self.source]
        while todo:
            a = todo.pop()
            for x, y in self.edges:
                if x == a and y not in seen and y not in gone:
                    seen.add(y)
                    todo.append(y)
        return self.sink in seen

    def single_points(self):
        return [c.name for c in self.components if not self.connected((c.name,))]

    def vendor_points(self):
        """Vendors whose failure removes every component they alone supply and so cuts the path."""
        vendors = sorted({v for c in self.components for v in c.vendors if v != IN_HOUSE})
        out = []
        for v in vendors:
            gone = [c.name for c in self.components if c.vendors == (v,)]
            if gone and not self.connected(gone):
                out.append(v)
        return out

The chapter’s example firm trades from Secaucus. Its stack: colocation and cross-connects from Equinix; a layer-1 fan-out from Arista and switches from Cisco, in parallel; an Exegy ticker plant and in-house feed handlers, in parallel; Blackcore servers with AMD network cards; its own execution gateway; and, off the path, order management from Trading Technologies, Meinberg grandmasters, Pico network analytics and a Quincy Data microwave route. It spends USD 3.19 million a year on them (synthetic figures).

Five components cut the path alone: colocation, cross-connects, the strategy servers, their network cards and the in-house gateway. Three vendors do: AMD, Blackcore and Equinix; Arista, Cisco and Exegy do not, because each has a parallel path. The Herfindahl–Hirschman index of the firm’s spend by vendor (shares of total spend, in-house work excluded from the index) is 1 149 on a scale of zero to 10 000, which reads as spread; but the index measures spend, not dependence: the firm’s largest vendor by spend, Equinix at 22.6%, is a point of failure, and its second, Quincy Data at 15.0%, is not.

Adding a second server vendor on half the servers lowers the index to 1 119 and removes Blackcore from the vendor points; the strategy servers remain a single component that can fail for other reasons. The exit times of the five single-point components add to 48 weeks: leaving Equinix alone is half a year. That is the practical meaning of vendor lock-in (Book 16, chapter 20, treats it as a business decision): not a contract clause but the weeks it takes to replace a component on the trading path.

27.6 Tutorial: one vendor too many

27.7 Build: the vendor map

27.8 Exercises

27.9 Problem: One Vendor Too Many

27.10 Interview questions