12The Asia-Pacific Map

India’s securities regulator received complaints in 2015 that the National Stock Exchange’s colocation facility sent its tick-by-tick data over TCP, member by member, in the order in which members had connected, so that “the first one to connect to the lowest load server would get advantage in terms of receiving the data faster than others”. Its 2019 order described the design in detail and directed the exchange to disgorge 624.89 crore rupees with interest; the appeals tribunal set the disgorgement aside, the regulator appealed, and on 18 September 2026 the Supreme Court allowed a settlement of about 1 492 crore rupees that closed the case. No cable was shorter and no server was faster: the advantage was built into the order in which one computer sent the same message to many.

This chapter maps the Asia-Pacific venues (Tokyo, Hong Kong, Singapore, Sydney, Mumbai) with the method of chapters 10 and 11, and then studies the case: what sequential dissemination does to the time at which each member sees a tick, what a randomiser and a second server change, and why multicast ends the problem. Distances in this region are thousands of kilometres, and several venues do not publish the address of their building, so the site table carries its precision with it.

12.1 Tokyo

JPX runs its co-location in what it calls the JPX Primary Site, where trading participants, information vendors and independent software vendors install their equipment next to the trading systems of the Tokyo Stock Exchange and the Osaka Exchange. JPX does not publish the building’s address; its network, arrownet, reaches the same trading systems from access points outside the site. The site table therefore places Tokyo at city level, which is an error of kilometres (tens of microseconds) and irrelevant at the scale of this map: Tokyo is $2880\,\mathrm{k}\mathrm{m}$ from Hong Kong, $9.6\,\mathrm{m}\mathrm{s}$ of light in vacuum and $14.0\,\mathrm{m}\mathrm{s}$ in straight fibre.

12.2 Hong Kong and Singapore

HKEX offers co-location, which it calls hosting services, in its own data centre in the Tseung Kwan O Industrial Estate, on the eastern side of Hong Kong. SGX is in the middle of a larger move. Its questions and answers on Iris-ST, its new trading platform, say that the platform will go live in a newly built primary data centre that members can also use for co-location, with the trading engine in a “2+1” arrangement (a primary and a hot standby in the primary data centre, a third instance at the secondary site). They also answer a question this chapter is about: from co-location, members will be able to receive the ITCH market data both over TCP and over multicast.

12.3 Sydney

ASX moved its equities trading platform into the Australian Liquidity Centre, a data centre at Gore Hill on Sydney’s North Shore, in February 2012. Its page states the two rules of chapter 9 in one sentence: every customer is given “identical length cross connects” to the trading platform wherever it sits in the building, and the building is carrier-neutral, so that its customers can bring their own networks. Sydney is the most isolated of the region’s centres: $6296\,\mathrm{k}\mathrm{m}$ from Singapore ($21.0\,\mathrm{m}\mathrm{s}$ in vacuum) and $7784\,\mathrm{k}\mathrm{m}$ from Tokyo. A trading firm in Sydney competes with other firms in the same building for ASX’s own markets, and with nobody nearby for anything else.

12.4 Mumbai and the colocation case

NSE’s tick-by-tick feed, according to SEBI’s order, was disseminated over TCP from June 2010 in the futures and options segment, and multicast arrived only in April 2014 (November 2014 in the cash market). The order describes the design in two levels. A dissemination centre sent each batch of ticks to the distribution (POP) servers, one after another, in the order in which the servers had logged in that day. Each POP server ran three sender processes, called ports, and each port sent to its own list of members, one after another, in the order in which the members had logged in. A member who logged in first, on a port of a server that had logged in first, was first in both queues; a member on a lightly loaded server, such as a backup server meant for business continuity, had fewer members ahead of it.

SEBI’s circular of May 2015 put the rule in regulatory form: exchanges must give co-located members “fair and equal access to facilities and data feeds”, must ensure that they “experience similar latency with respect to exchange provided infrastructure”, and must publish quarterly latency reports. The definition has two parts because the case had two. The spread says how much faster the first recipient is than the last. The persistence says whether it is always the same one: a random order with a large spread gives everyone a turn at being first; a fixed order gives one member every race.

def unicast_us(servers, c_centre=5.0, c_send=10.0, jitter=1.0, rng=None, shuffle=False):
    """Receive time of one tick: the centre's copy to each server in server order, then each
    port's sends in login order. shuffle=True redraws both orders for this tick (a randomiser)."""
    rng = rng or np.random.default_rng(0)
    out = {}
    order = list(range(len(servers)))
    if shuffle:
        rng.shuffle(order)
    for q, i in enumerate(order):
        s = servers[i]
        at_server = (q + 1) * c_centre
        for p, n in enumerate(s.ports):
            ranks = rng.permutation(n) if shuffle else np.arange(n)
            noise = _noise(rng, jitter, n)
            for r in range(n):
                slot = int(ranks[r])
                out[Member(s.name, p, r)] = at_server + (slot + 1) * c_send * s.speed + noise[r]
    return out

Figure 12.3 and Table 12.2 run the model with parameters chosen for illustration, not taken from the order. Under plain unicast, the first member receives a tick after $16\,\text{µ}\mathrm{s}$ and the median member after $66\,\text{µ}\mathrm{s}$; the order is the same tick after tick (a rank correlation of 1.00), so the member who was first on one tick beats the median member on every later one. A randomiser, which the order says NSE had developed in 2011 but not implemented in this feed’s dissemination, redraws the order for every tick: the spread does not change, but the rank correlation falls to 0.07. It still leaves the lightly loaded server: in the model the first member of a randomised tick is usually one of the secondary server’s six, and it beats the median member 88% of the time. Closing the secondary to normal traffic brings that to 51%, a coin toss; multicast shrinks the spread itself from about $108\,\text{µ}\mathrm{s}$ to the jitter.

    out = {}
    for name, kind, shuffle, topo in DESIGNS:
        rng = np.random.default_rng(seed)
        t0 = _tick(kind, shuffle, rng, topo)
        a, b = _first_and_median(t0)
        wins = [fd.race_win(_tick(kind, shuffle, rng, topo), a, b, n=200, seed=k) for k in range(ticks)]
        stab = fd.rank_stability(topo, seed=seed, shuffle=shuffle, **PARAMS) if kind == "u" else None
        out[name] = {**fd.fairness(t0), "stability": stab, "win_first": float(np.mean(wins))}
    return out

The lesson for a trading firm is not only historical. Wherever a venue or a vendor distributes data over one connection per client (a TCP feed, a websocket stream in chapter 20, a cloud relay in chapter 16), the order of the copies is a latency that no cable can fix, and the questions of this section apply: in what order are the copies sent, does the order change, and who sits on the quieter server.

12.5 Onshore China and its restrictions

China’s securities regulator has regulated co-location as a question of fairness. Its Administrative Rules for Program Trading in the Securities Market, issued in May 2024 and in force from 8 October 2024, require an exchange that offers co-location to follow the principles of “safety, fairness and reasonableness” and to allocate the resources fairly, and brokers to keep trading fair between their clients; the exchanges’ accompanying notice singles out for monitoring accounts that reach 300 orders or cancellations a second, or 20 000 in a day. A consultation of April 2023 on trading-server co-location proposed that exchanges manage co-location in dedicated areas and keep the communication latency from those areas to the front-end processors of the core trading system consistent: the equal-cable rule of chapter 9, written as a latency requirement.

12.6 Tutorial: dissemination order

12.7 Build: the dissemination model

12.8 Exercises

12.9 Problem: First to Log In

12.10 Interview questions