---
title: "FX Connectivity"
book: "Networks, Hardware and Trading Infrastructure"
subject: quant
language: en
chapter: 24
exercises: 8
source: https://one-course.com/books/quant/14/en/chapter/24-fx-connectivity
---

# Chapter 24 — FX Connectivity

On EBS each currency pair now matches in one place, New York or London, and a trader in Tokyo reaches it through a gateway that forwards the order across an ocean or a continent. A liquidity provider in London that streams prices to Tokyo quotes on information that is two Eurasian crossings old by the time a Tokyo taker sees it: 141 milliseconds at a specialist’s [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor). Yet the provider’s price check needs no hold to catch a Tokyo taker who saw the news first, as long as the provider learns of the news as fast as the taker’s request travels. When it learns more slowly, the hold that would close the gap is a delay the market’s code of conduct does not allow.

Book 2 described the FX market’s structure: primary venues, ECNs, single-dealer platforms, prime brokerage, streaming quotes, last look and hold times. Book 10 introduced the liquidity aggregator and Book 13 the FIX session. This chapter puts them on the map of chapters 10 to 12: where FX matching happens, where credit is checked, how a liquidity provider’s streams reach the sites, and what aggregators see. The venues’ sites are dated rows; the staleness model is labelled as such.

## 24.1 The matching sites

**Definition 24.1 (Multi-site matching).**

*Multi-site matching* is a venue design in which matching engines run in several data centres, each instrument is matched at exactly one of them, and gateways at the other sites forward orders to the instrument’s engine rather than match them locally.

**As of September 2026 — Where FX venues match and stream, from their connectivity documents.**

- EBS Market on CME Globex: each product trades in a single location. New York FX spot and metals in Equinix Secaucus NY5 (backup in Slough LD4.2); London FX spot and NDFs in LD4.2 (backup in NY5). Tokyo TY3 has only a convenience gateway, routing orders to New York or London, and credit-screened conflated market data; an order sent to a segment gateway for an instrument not matched there is rejected. Shared services, including global credit limits, in Chicago DC3.
- LSEG FX (guide of June 2026): Spot and Forwards Matching in London LD4 (recovery in NY6); PriceStream streams and aggregation in New Jersey NY6, London LD4 and Tokyo TY3; NDF Matching in Singapore SG3 (recovery in LD4); [colocation](https://one-course.com/books/quant/14/en/chapter/9-colocation-products-and-how-they-are-sold#def-nw-colocation-products-and-how-they-are-sold-colo) [cross-connects](https://one-course.com/books/quant/14/en/chapter/9-colocation-products-and-how-they-are-sold#def-nw-colocation-products-and-how-they-are-sold-mmr) at LD4, TY3, NY4/NY5 and SG1, with equal cable lengths within the main buildings.

FX has no single exchange per pair: the same pair is quoted on several venues, each with its own sites, and every venue that matches a pair matches it in one place. The map is therefore short: Slough, Secaucus, Tokyo and Singapore ([Table 24.1](#tab-nw-fx-connectivity-floors)). London LD4 is where the London engines are and where the London liquidity providers sit; the Secaucus campus hosts EBS’s New York engine and LSEG’s New Jersey streams; TY3 is an access and streaming site with no EBS matching; SG1 and SG3 serve LSEG’s NDFs.

| From London LD4 to | Fibre floor, one way (ms) | At 1.5 (ms) | Round trip at 1.5 (ms) |
| --- | --- | --- | --- |
| Secaucus NY5 and NY6 | 27.07 | 40.6 | 81.2 |
| Tokyo TY3 | 46.85 | 70.3 | 140.5 |
| Singapore SG1 | 53.10 | 79.7 | 159.3 |

***Table 24.1.** One-way fibre floors from London LD4 to the other FX sites (chapter 10’s geodesic and [group index](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-floor), site coordinates in `data/networks/sites.csv`), and at chapter 19’s specialist [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) of 1.5. Data: `firm_fxlinks.one_way_ms`.*

A Tokyo trader’s order to the EBS engines crosses the Tokyo gateway and the network: at a [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) of 1.5 and $40\,\text{µ}\mathrm{s}$ of gateway, credit screen and matching stages (assumptions), $79.5\,\mathrm{m}\mathrm{s}$ to New York and $70.3\,\mathrm{m}\mathrm{s}$ to London, one way.

## 24.2 Credit checks in the order path

**Definition 24.2 (Bilateral credit screen).**

A *bilateral credit screen* is a venue’s filter that lets two participants trade, and shows each only the other’s prices, when both have granted each other credit; it applies in the market data a participant receives and in the matching of its orders.

FX venues are mostly bilateral underneath: a trade is a contract between two named firms, settled between them or their prime brokers, so each must have granted the other credit. EBS shows each firm a credit-screened book, the price levels it could actually trade, beside a “market best” that ignores credit, and warns that the screened quantity may exceed what is tradeable. The credit check is therefore in two places on the path: in the data (what the firm is shown) and in matching (what it can trade), and a firm’s apparent best price may not be its best tradeable one.

For a liquidity provider, credit is also the first half of last look. The FX Global Code’s Principle 17 names two checks, validity, including “sufficient available credit”, and price; and the Global Foreign Exchange Committee’s 2021 report adds that “any delay that is additional to what is required to complete the price and validity check is considered contrary to Principle 17” ([Box 24.2](#dat-nw-fx-connectivity-lastlook)).

**As of September 2026 — Last look, from the FX Global Code and its committee.**

Principle 17: last look is a risk control to check validity (operational details and sufficient available credit) and price (whether the requested price “remains consistent with the current price that would be available to the Client”). GFXC report on last look (August 2021): an additional delay beyond the checks is contrary to Principle 17; liquidity providers should disclose their last look window’s maximum and minimum length.

## 24.3 Integrating as a liquidity provider

A liquidity provider in London learns of a price move at its origin, prices it and streams the new quote to every venue site. A taker at a venue site learns of the same move by its own path. The quote’s staleness at the site is the provider’s lag less the taker’s; a taker who hits the stale quote sends a request back to the provider, which checks the price when the request arrives, or after a hold.

```python
def staleness_ms(origin, lp, venue, paths, table):
    lp_lag = one_way_ms(origin, lp, paths.info, table) + paths.proc_ms
    lp_lag += one_way_ms(lp, venue, paths.stream, table)
    return lp_lag - one_way_ms(origin, venue, paths.taker, table)


def hold_ms(origin, lp, venue, paths, table):
    knows = one_way_ms(origin, lp, paths.info, table) + paths.proc_ms
    arrives = one_way_ms(origin, venue, paths.taker, table)
    arrives += one_way_ms(venue, lp, paths.request, table)
    return max(0.0, knows - arrives)
```

***Listing 24.1.** Staleness at a venue site, and the hold before the price check that would let the provider know what the taker knew. code/firm/fxlinks/firm_fxlinks.py*

**Proposition 24.3 (When no hold is needed).**

If the provider’s information path from the origin is no slower than the taker’s path from the origin followed by the request’s path to the provider, the provider’s price check at arrival already reflects every move the taker could have seen; the hold that closes the gap is the provider’s lag less that sum, and zero otherwise.

**Proof.** A move at time $\tau$ reaches the taker at $\tau + d_T$ and, through the request, the provider no earlier than $\tau + d_T + d_R$; the provider knows of it at $\tau + d_I + p$. The check at arrival plus a hold $h$ reflects the move if and only if $d_I + p \le d_T + d_R + h$. ∎

With every path at a [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) of 1.5, the triangle inequality makes the hold the provider’s processing alone, whatever the staleness. For a move in Tokyo, the London provider’s quote reaches the Tokyo site $140.6\,\mathrm{m}\mathrm{s}$ after the Tokyo taker knew of it; the taker’s request then takes $70.3\,\mathrm{m}\mathrm{s}$ back to London, where the provider learned of the move $70.3\,\mathrm{m}\mathrm{s}$ after it happened. The price check at arrival catches it (with the model’s jitter of $0.5\,\mathrm{m}\mathrm{s}$ a leg, 70% at once and 99.4% after a two-millisecond hold). If instead the provider learns of Tokyo moves over a backbone at 2.46 times the floor, its quote is $185.6\,\mathrm{m}\mathrm{s}$ stale at the Tokyo site and the hold that would close the gap is $45.1\,\mathrm{m}\mathrm{s}$: the difference between the two [route factors](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) times the floor.

```python
def tokyo():
    floor = fx.one_way_ms("ty3", LP, 1.0, SITES)
    return {"floor": floor, "stale_equal": fx.staleness_ms("ty3", LP, "ty3", EQUAL, SITES),
            "stale_backbone": fx.staleness_ms("ty3", LP, "ty3", BACKBONE, SITES),
            "hold_equal": fx.hold_ms("ty3", LP, "ty3", EQUAL, SITES),
            "hold_backbone": fx.hold_ms("ty3", LP, "ty3", BACKBONE, SITES)}
```

***Listing 24.2.** The weekend problem’s numbers: a Tokyo move, the Tokyo site, a London provider. code/networks/24-fx-connectivity/python/nw_fx.py*

![Model: how stale a London liquidity provider’s quote is at each FX site (London LD4, Secaucus NY5 and NY6, Tokyo TY3, Singapore SG1), after a move in New York or in Tokyo, every path at 1.5 times the fibre floor and 0.1\, m s of pricing. A move in London leaves every site 0.1\, m s stale. Data: fig_fx.py, nw_fx.staleness_table().](https://one-course.com/images/onecourse/chapters/quant-14/nw-fx-connectivity/fig-fe42e4529964.svg)

***Figure 24.1.** Model: how stale a London liquidity provider’s quote is at each FX site (London LD4, Secaucus NY5 and NY6, Tokyo TY3, Singapore SG1), after a move in New York or in Tokyo, every path at 1.5 times the fibre floor and $0.1\,\mathrm{m}\mathrm{s}$ of pricing. A move in London leaves every site $0.1\,\mathrm{m}\mathrm{s}$ stale. Data: `fig_fx.py`, `nw_fx.staleness_table()`.*

![Model: the share of trade requests from a Tokyo taker who saw a Tokyo move first that the London provider’s price check catches, against the hold before the check, with exponential jitter of 0.5\, m s on each leg. With an information path as fast as the request’s, a two-millisecond hold catches 99.4%; with a backbone, 47 milliseconds are needed. Data: fig_fx.py, nw_fx.caught_curves().](https://one-course.com/images/onecourse/chapters/quant-14/nw-fx-connectivity/fig-eb2940b42a0e.svg)

***Figure 24.2.** Model: the share of trade requests from a Tokyo taker who saw a Tokyo move first that the London provider’s price check catches, against the hold before the check, with exponential jitter of $0.5\,\mathrm{m}\mathrm{s}$ on each leg. With an information path as fast as the request’s, a two-millisecond hold catches 99.4%; with a backbone, 47 milliseconds are needed. Data: `fig_fx.py`, `nw_fx.caught_curves()`.*

The Code settles which fix is allowed. A hold beyond what the checks require is contrary to Principle 17, so the provider cannot buy back a slow information path with a longer last look window; it must make the path faster, or price Tokyo moves in Tokyo, which is what streaming sites such as LSEG’s PriceStream in TY3 allow. Staleness itself is not the provider’s to remove: a quote made in London is a round trip old in Tokyo, and the only remedy for a taker who wants fresh London prices in Tokyo is a provider that quotes from Tokyo.

## 24.4 Aggregators

An aggregator combines several providers’ streams and shows the best. After a move, the providers whose quotes arrive last are the ones whose prices have not moved, and their stale prices are the best on the side the market moved away from: the aggregator selects the stalest quote exactly when it is stale. At an aggregator in Tokyo, after a Tokyo move, a Tokyo provider’s quote is fresh, a London provider’s stays stale for $140.5\,\mathrm{m}\mathrm{s}$ and a New Jersey provider’s for $158.9\,\mathrm{m}\mathrm{s}$ (`firm_fxlinks.stale_window_ms`). This is the provider’s side of chapter 19’s races: a provider is picked off in proportion to its distance from the moves of the pairs it quotes, and an aggregator makes the picking-off systematic. The provider’s defences are the ones above: a fast information path, pricing near the origin, and a price check without added delay.

**Method 24.4 (Connecting as an FX liquidity provider).**

1. List the venues and their sites for each pair: where it matches, where it streams, where the gateways are.
2. For each pair, find where its moves originate, and compare the provider’s information path with the takers’ paths and the request path back ( [Proposition 24.3](#prop-nw-fx-connectivity-hold) ).
3. Where the provider’s information path is slower, shorten it or price from a site near the origin; never lengthen the last look window to compensate.
4. Keep credit consistent across venues and in the validity check, and measure rejects by reason.
5. Measure staleness at each site from your own timestamps, and the fills that follow moves you had not yet seen.

![A London provider’s streams to the FX sites, one way at 1.5 times the fibre floor, and the Tokyo gateway that forwards orders to the engines. Schematic; distances as in .](https://one-course.com/images/onecourse/chapters/quant-14/nw-fx-connectivity/fig-7ad9dc3ea20c.svg)

***Figure 24.3.** A London provider’s streams to the FX sites, one way at 1.5 times the fibre floor, and the Tokyo gateway that forwards orders to the engines. Schematic; distances as in [Table 24.1](#tab-nw-fx-connectivity-floors).*

## 24.5 Tutorial: staleness at every site

**Goal.** Compute how stale a London provider’s quotes are at the FX sites, and what its price check needs to catch the takers who saw the move first. **End state:** Figures [24.1](#fig-nw-fx-connectivity-staleness) and [24.2](#fig-nw-fx-connectivity-caught).

1. **Sites.** `firm_fxlinks.load_venues` and `sites` read the dated venue rows and the coordinates.
2. **Staleness.** `staleness_ms` and `hold_ms` ( [Listing 24.1](#lst-nw-fx-connectivity-stale) ) for every origin and site, with `Paths` for the [route factors](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) .
3. **Checks.** `caught` adds jitter and counts the informed requests caught after each hold; `nw_fx.tokyo` ( [Listing 24.2](#lst-nw-fx-connectivity-tokyo) ) gives the problem’s numbers.

**What to change next.** Give each taker a microwave path where one exists (chapter 14) and see which sites’ holds jump; add a second provider in Tokyo and measure what an aggregator there selects.

## 24.6 Build: the FX connectivity model

**Purpose.** Where FX venues match and stream, and what a provider’s streams and price checks see at each site: the FX rows of chapter 29’s plan.

**Interface.** `firm_fxlinks`: `Venue`, `load_venues`, `sites`, `one_way_ms`, `Paths`, `staleness_ms`, `hold_ms`, `caught`, `stale_window_ms`, `order_path_ms`.

**Rules.** Venue sites are dated rows with sources; paths are fibre floors times stated [route factors](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor); jitter and processing are stated assumptions; results are a model.

**Acceptance tests.** `code/firm/fxlinks/tests/`: the venue table, no hold with equal paths for every origin and site, the hold equal to the route-factor gap, and the stale windows and order path.

**Stretch.** Microwave paths for takers; several providers at several sites; credit limits per counterparty in the order path.

Sources and further reading

- CME Group Client Systems Wiki: EBS Market on CME Globex Market Functionality; iLink Binary Order Entry for EBS; credit-screened market data for EBS.
- LSEG, FX Venues Colo Connectivity Technical Deployment Guide, version 2.6 (June 2026).
- Global Foreign Exchange Committee, Report on Last Look (August 2021), and the FX Global Code, Principle 17.

## 24.7 Exercises

**Exercise 24.1 ★.**

Where does EBS match New York FX spot, and where does it match London FX spot and NDFs?

**Solution of Exercise 24.1.**

New York FX spot (and metals) in Equinix Secaucus NY5, with a backup in Slough LD4.2; London FX spot and NDFs in LD4.2, with a backup in NY5. Each product trades in a single location.

**Exercise 24.2 ★.**

What does a credit-screened book show a firm, and why may its quantity mislead?

**Solution of Exercise 24.2.**

Only the price levels where the firm has bilateral credit with the counterparties; the quantity at a level may include orders it cannot trade with, so it may exceed what the firm can fill.

**Exercise 24.3 ★.**

What is the one-way fibre floor from LD4 to TY3, and the round trip at a [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) of 1.5?

**Solution of Exercise 24.3.**

$46.85\,\mathrm{m}\mathrm{s}$ one way; at 1.5, $70.3\,\mathrm{m}\mathrm{s}$ one way and $140.5\,\mathrm{m}\mathrm{s}$ round trip.

**Exercise 24.4 ★★.**

Using [Proposition 24.3](#prop-nw-fx-connectivity-hold), why does a move in London leave the London provider’s quotes only $0.1\,\mathrm{m}\mathrm{s}$ stale at every site?

**Solution of Exercise 24.4.**

The provider is at the origin: its quote leaves for each site as soon as it has priced the move, over a path as fast as the taker’s, so the only difference is the $0.1\,\mathrm{m}\mathrm{s}$ of pricing.

**Exercise 24.5 ★★.**

A Tokyo trader sends an order for a New York-matched pair through the Tokyo gateway. How long does it take to reach the engine in the model, and what would a New York server gain?

**Solution of Exercise 24.5.**

$79.5\,\mathrm{m}\mathrm{s}$: the network at 1.5 plus $40\,\text{µ}\mathrm{s}$ of stages. A server in Secaucus next to the engine would save almost all of it, but would learn of Tokyo news $79.5\,\mathrm{m}\mathrm{s}$ late, so it helps only for New York-driven trading.

**Exercise 24.6 ★★.**

Why does an aggregator tend to show the stalest quote after a move?

**Solution of Exercise 24.6.**

After a move, the quotes that have not yet moved are the best on the side the market moved away from, and they come from the providers furthest from the move; the aggregator selects them because they look best, exactly while they are stale.

**Exercise 24.7 ★★★.**

*Coding.* With `firm_fxlinks.caught`, what hold catches 99% of informed requests when the provider’s information path is at 2.46 and the model’s jitter is $0.5\,\mathrm{m}\mathrm{s}$?

**Solution of Exercise 24.7.**

$47\,\mathrm{m}\mathrm{s}$: 99.4% are caught; at $46\,\mathrm{m}\mathrm{s}$, 96.2%.

**Exercise 24.8 ★★★.**

*Find the flaw.* “Our Tokyo fills are toxic because our quotes are 140 milliseconds stale there; a 150-millisecond last look window will fix it.”

**Solution of Exercise 24.8.**

Staleness is not what the check must cover: with equal paths the price check at arrival already knows the move. If the fills are toxic, the provider’s information path is slower than the takers’; a window longer than the checks need is contrary to Principle 17. The fix is a faster information path or pricing in Tokyo.

## 24.8 Problem: USDJPY at Three Sites

**Problem 24.1.**

Weekend problem — a London provider’s quotes at the Tokyo site

A liquidity provider in London LD4 streams USDJPY to venues in London, Secaucus and Tokyo. Suppose the news that moves USDJPY breaks in Tokyo. Use the chapter’s model: every path at 1.5 times the fibre floor unless stated, $0.1\,\mathrm{m}\mathrm{s}$ of pricing, and jitter of $0.5\,\mathrm{m}\mathrm{s}$ a leg where asked.

**Part I — Distances.**

1. What are the one-way fibre floors from LD4 to NY5 and to TY3?
2. What are they at a [route factor](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) of 1.5?
3. How stale is the provider’s quote at each site after a Tokyo move?
4. And after a New York move?

**Part II — The price check.**

5. With every path at 1.5, what hold does the price check need to catch a Tokyo taker who saw a Tokyo move?
6. What share does the check catch at once, and after two milliseconds, with the jitter?
7. If the provider learns of Tokyo moves over a backbone at 2.46, what is the staleness and the hold?
8. What hold catches 99% then?

**Part III — The rules.**

9. What does Principle 17 say the checks are for?
10. Can the provider lengthen its window to $45\,\mathrm{m}\mathrm{s}$ ?
11. What are its allowed remedies?
12. Where would a Tokyo pricing engine sit, and what would it change for the Tokyo site?

**Part IV — The verdict.**

13. State the *named result* : the quote staleness at the Tokyo site of a London-hosted provider, and the hold time that would neutralise it.
14. Which numbers are published and which assumed?
15. What does an aggregator in Tokyo see after a Tokyo move?
16. How should the provider measure its staleness in production?
17. What does the Tokyo gateway mean for a Tokyo taker on EBS?
18. How would microwave paths for takers change the result?
19. Where does this go in chapter 29’s plan?
20. In one sentence: what decides whether last look can protect a distant provider?

**Solution of Problem 24.1.**

**Part I.**

1. $27.07\,\mathrm{m}\mathrm{s}$ and $46.85\,\mathrm{m}\mathrm{s}$ .
2. $40.6\,\mathrm{m}\mathrm{s}$ and $70.3\,\mathrm{m}\mathrm{s}$ .
3. $140.6\,\mathrm{m}\mathrm{s}$ at TY3, $31.5\,\mathrm{m}\mathrm{s}$ at NY5 and NY6, $111.1\,\mathrm{m}\mathrm{s}$ at SG1, and $0.1\,\mathrm{m}\mathrm{s}$ at LD4, where the taker learns of it no sooner than the provider.
4. $81.3\,\mathrm{m}\mathrm{s}$ at NY5 and NY6, $31.5\,\mathrm{m}\mathrm{s}$ at TY3, $8.2\,\mathrm{m}\mathrm{s}$ at SG1 and $0.1\,\mathrm{m}\mathrm{s}$ at LD4.

**Part II.**

1. None beyond the pricing time: $0.1\,\mathrm{m}\mathrm{s}$ .
2. 70% at once and 99.4% after $2\,\mathrm{m}\mathrm{s}$ .
3. $185.6\,\mathrm{m}\mathrm{s}$ and $45.1\,\mathrm{m}\mathrm{s}$ .
4. $47\,\mathrm{m}\mathrm{s}$ .

**Part III.**

1. A validity check, including sufficient available credit, and a price check against the current price available to the client.
2. No: a delay beyond what the checks need is contrary to Principle 17.
3. A faster information path from Tokyo, or pricing Tokyo moves from a server in Tokyo; disclosed, prompt checks.
4. In TY3, where the streams to the Tokyo site start: the Tokyo site’s quotes would be fresh after Tokyo moves, and stale after London and New York ones instead.

**Part IV.**

1. *Named result* : a London provider’s USDJPY quote is $140.6\,\mathrm{m}\mathrm{s}$ stale at the Tokyo site after a Tokyo move with every path at 1.5 times the floor, and $185.6\,\mathrm{m}\mathrm{s}$ if it learns of Tokyo moves over a backbone at 2.46; the hold that would neutralise it is only the pricing time with equal paths, and $45.1\,\mathrm{m}\mathrm{s}$ (47 to catch 99% with jitter) with the backbone, a delay the Code does not allow, so the remedy is the path, not the window.
2. Published: the sites, the Code’s text, chapter 19’s [route factors](https://one-course.com/books/quant/14/en/chapter/10-the-north-american-map#def-nw-the-north-american-map-factor) . Assumed: the factors applied to these routes, the pricing time, the jitter, and where the news breaks.
3. The Tokyo provider’s quote fresh, the London provider’s stale for $140.5\,\mathrm{m}\mathrm{s}$ , the New Jersey provider’s for $158.9\,\mathrm{m}\mathrm{s}$ ; it selects the stale ones on the side the market left.
4. Timestamp each quote at creation and at each venue’s acknowledgement or market data echo, and compare fills with its own mid a short time later, per site and per origin of the move.
5. Its orders are forwarded to New York or London, so it trades on the engine’s time, a crossing away, whatever its gateway.
6. They shorten the takers’ paths: the provider’s information path is then slower than theirs, and the hold needed grows by the difference, again a matter of paths, not windows.
7. In the FX rows: the venues and sites per pair, the provider’s pricing sites and paths, credit, and the staleness monitoring.
8. Whether the provider learns of a move as fast as the taker’s request can reach it.

## 24.9 Interview questions

**Interview question 24.1 ★ developer.**

Where would you put servers to trade spot FX on the main venues, and why?

**Solution of Interview question 24.1.**

In LD4 in Slough and on the Secaucus campus, where the main engines and streams are, with a presence in TY3 for Tokyo clients and streaming; SG1 for NDFs. Each pair matches in one place, so the servers go where the pairs you trade match and where their news breaks.

*What the interviewer is looking for: Engines per pair; the Slough and Secaucus campuses; Tokyo as access and streaming.*

**Interview question 24.2 ★★ trader.**

What is last look for, and what is it not for?

**Solution of Interview question 24.2.**

A risk control for validity, including credit, and price, applied promptly; it is not a free option, a source of information for trading against the client, or a way to add delay beyond the checks.

*What the interviewer is looking for: Principle 17; validity and price; no added delay; disclosure.*

**Interview question 24.3 ★★ developer, researcher.**

How would you measure how stale your quotes are at each venue?

**Solution of Interview question 24.3.**

Timestamp quotes at creation on a synchronised clock, read the venues’ market data or acknowledgements with their timestamps at each site, and compare with the moment the move that should have changed the quote reached each site by the fastest path.

*What the interviewer is looking for: Clock synchronisation; per-site measurement; the fastest path as reference.*

**Interview question 24.4 ★★ developer.**

Your fills on one venue have become toxic since a network change. What do you look at?

**Solution of Interview question 24.4.**

Whether the provider’s information path changed (a route, a vendor, a switch), whether takers gained a faster path, the rejects by reason, and the fills against the mid a few milliseconds later, per site.

*What the interviewer is looking for: Paths on both sides; markouts; reject reasons.*

**Interview question 24.5 ★★ researcher.**

Why can an aggregator’s best price be worse than it looks?

**Solution of Interview question 24.5.**

It is the maximum over stale and fresh quotes, and after a move the stale ones are the best; with bilateral credit and last look, the best shown price may also be one the client cannot trade or that will be rejected.

*What the interviewer is looking for: Selection of stale quotes; credit screening; rejects.*

**Interview question 24.6 ★★★ developer, researcher.**

Design the pricing and streaming infrastructure of a liquidity provider quoting G10 pairs to clients in London, New York and Tokyo.

**Solution of Interview question 24.6.**

Pricing engines in London, Secaucus and Tokyo, each fed by the fastest paths from the others and from the pairs’ main markets; streams from the nearest engine to each site; one credit service consistent across venues; prompt, disclosed price and validity checks; staleness and markouts measured per site.

*What the interviewer is looking for: Pricing near the news; path parity; credit; monitoring.*