---
title: "Fixed Income and RFQ Platform Connectivity"
book: "Networks, Hardware and Trading Infrastructure"
subject: quant
language: en
chapter: 25
exercises: 8
source: https://one-course.com/books/quant/14/en/chapter/25-fixed-income-and-rfq-platform-connectivity
---

# Chapter 25 — Fixed Income and RFQ Platform Connectivity

On a request-for-quote platform the client’s [quote timer](#def-nw-fixed-income-and-rfq-platform-connectivity-timer) runs for seconds, not microseconds; yet dealers answer in milliseconds. A response that arrives after the timer is not a worse price but no price at all, and some clients no longer wait for the timer: their rules execute the best of the first few answers, or the first acceptable one. Under those rules a dealer twenty milliseconds slower than a rival loses trades it would have won on price, and the chapter’s model finds that halving an auto-responder’s pricing time is worth nearly fifteen times more than bidding a cent better.

Book 2 described request-for-quote trading, dealer-to-client platforms, inter-dealer brokers and all-to-all trading; Book 11 built the auto-quoter with its win-probability model and cover price; Book 13 the FIX session and the latency budget. This chapter connects them: the platforms’ interfaces, the auto-responder’s pipeline from request to answer, the latency that matters when the clock is a [quote timer](#def-nw-fixed-income-and-rfq-platform-connectivity-timer), and the inter-dealer order books, which are exchanges in all but name and sit in the data centres of chapter 10 and 11. The auction is a labelled simulation on Book 11’s price model.

## 25.1 Platform interfaces

A dealer connects to each dealer-to-client platform through a FIX session or the platform’s own interface, receives requests, and answers them with firm prices valid for a stated time. The platforms’ protocols differ in what the client sees and how long the dealer’s price binds ([Box 25.1](#dat-nw-fixed-income-and-rfq-platform-connectivity-platforms)): a one-sided request, a two-sided request for market that hides the client’s side, a request for stream in which dealers update their prices every 250 milliseconds, or a price with a “wire time” during which it can be hit.

**Definition 25.1 (Quote timer).**

A *quote timer* is the period, set by the platform or the client for each request for quote, during which dealers’ answers are collected and remain executable; an answer that arrives after it expires is not shown, and a price shown during it binds the dealer until the client trades, passes or the timer runs out.

**As of September 2026 — Request-for-quote protocols and automation, from the platforms.**

- TW SEF’s protocols (advisory of 2015): an RFQ is “a real-time auction with multiple RFQ recipients” in which the requester selects the best price; at least three unaffiliated recipients for required transactions; request for market; RFQ+ beside the order book; request for stream, with prices updated “every 250 milliseconds”; otherwise a price with a “wire time”.
- Tradeweb’s AiEX executes orders from the client’s order management system by pre-defined rules; a client might “execute at the best price once they get five responses” or wait for a particular dealer (2018).
- MarketAxess (June 2023): automation protocols were “nearly 10% of total trading volume” in the year to date; its Adaptive Auto-X was in pilot.

## 25.2 Auto-responding: the pipeline from request to answer

An auto-responder is a pipeline: the request arrives over the network and the FIX engine; the pricer values the bond (Book 11’s fair value from stale prints, the issuer curve and comparables); limits and risk are checked; the answer goes back. Each stage has a latency distribution, and requests the auto-responder is not allowed to answer, for size, liquidity or risk, go to a person, who answers in seconds.

```python
def response_ms(p, n, rng):
    t = np.zeros(n)
    for s in p.stages:
        t += s.median_ms * np.exp(s.sigma * rng.standard_normal(n))
    manual = rng.random(n) < p.manual_share
    t[manual] += p.manual_median_ms * np.exp(p.manual_sigma * rng.standard_normal(int(manual.sum())))
    return t
```

***Listing 25.1.** An answer’s time: the stages’ lognormal times, plus a person’s for the share outside the auto-responder’s limits. code/firm/rfqlink/firm_rfqlink.py*

The chapter’s dealer has five stages (network in and out $0.5\,\mathrm{m}\mathrm{s}$ each, FIX engine $0.1\,\mathrm{m}\mathrm{s}$, pricing $20\,\mathrm{m}\mathrm{s}$, limits $1\,\mathrm{m}\mathrm{s}$, medians with lognormal spreads) and sends 2% of requests to a person, whose answers take six seconds at the median. Its four competitors are identical except for a pricing stage of $50\,\mathrm{m}\mathrm{s}$. All of it is assumption, in the range an auto-responder can be built to (Book 13).

**Definition 25.2 (Automated execution rule).**

An *automated execution rule* is a client’s pre-set instruction, run by the platform, that executes a request for quote without a person’s decision: at the best answer when the timer expires, at the best of the first $k$ answers, at the first answer within a tolerance of a reference price, or with a named dealer.

## 25.3 Latency that matters when the clock is a quote timer

Two latencies matter. The first is whether the answer arrives before the timer: with a two-second timer the automatic stages never miss, and the chance of missing is almost exactly the share sent to a person times the chance a person takes more than two seconds, 1.94% for the chapter’s dealer ([Figure 25.1](#fig-nw-fixed-income-and-rfq-platform-connectivity-miss)). The second is whether the answer arrives before the answers that the client’s rule will take, which depends on the rule.

![Simulation: the chance that the chapter’s dealer answers after the quote timer, against the timer’s length. Fully automatic, it never misses a timer of one second or more; with 2% of requests answered by a person (six seconds at the median), it misses 1.94% of two-second timers, and the plateau is the person, not the network. Data: fig_rfq.py, nw_rfq.miss_curves().](https://one-course.com/images/onecourse/chapters/quant-14/nw-fixed-income-and-rfq-platform-connectivity/fig-a509088cd9a0.svg)

***Figure 25.1.** Simulation: the chance that the chapter’s dealer answers after the [quote timer](#def-nw-fixed-income-and-rfq-platform-connectivity-timer), against the timer’s length. Fully automatic, it never misses a timer of one second or more; with 2% of requests answered by a person (six seconds at the median), it misses 1.94% of two-second timers, and the plateau is the person, not the network. Data: `fig_rfq.py`, `nw_rfq.miss_curves()`.*

The client’s rule decides the rest. The auction draws each dealer’s bid as Book 11 does, the dealer’s noisy estimate of the bond’s value less a markup of 15 cents per 100 face, and the client sells only at or above its reservation price; with every answer in time and the rule “best at expiry”, the simulation is Book 11’s auction exactly (the tests check it). Then the rules part ways.

```python
    in_time = t <= timer_ms
    ok = in_time & (bids >= reservation[:, None])
    if rule == "expiry":
        chosen = np.where(ok, bids, -np.inf).argmax(axis=1)
    elif rule == "first_k":
        order = np.argsort(np.where(in_time, t, np.inf), axis=1)
        first = np.zeros_like(ok)
        np.put_along_axis(first, order[:, :k], True, axis=1)
        chosen = np.where(ok & first, bids, -np.inf).argmax(axis=1)
        ok = ok & first
    elif rule == "first_ok":
        chosen = np.where(ok, t, np.inf).argmin(axis=1)
    else:
        raise ValueError(rule)
    traded = ok.any(axis=1)
    win = traded & (chosen == 0)
    best_ok = np.where(in_time & (bids >= reservation[:, None]), bids, -np.inf).argmax(axis=1)
    lost = traded & ~win & (best_ok == 0)
```

***Listing 25.2.** The three client rules, and the requests lost to speed: our answer was the best acceptable one in time, and the rule chose another. code/firm/rfqlink/firm_rfqlink.py*

**Proposition 25.3 (When speed is worth nothing).**

Under the rule “best at expiry”, a dealer’s win rate depends on its response time only through the chance of missing the timer; under “best of the first $k$” and “first acceptable”, it falls with the dealer’s rank in arrival order, so a faster answer at the same price wins more.

**Proof.** At expiry the client compares all answers that arrived in time, whatever their order. Under the other rules, an answer outside the first $k$, or behind an earlier acceptable one, is never compared, and a faster pipeline raises its chance of being among them. ∎

![Simulation: the share of requests the dealer wins among five, against its pricing time, under three client rules, all dealers at the same markup. At expiry the curve is flat until the pricing time’s tail reaches the timer, at hundreds of milliseconds; under the other two rules every millisecond counts. Data: fig_rfq.py, nw_rfq.curves().](https://one-course.com/images/onecourse/chapters/quant-14/nw-fixed-income-and-rfq-platform-connectivity/fig-78d4b8346016.svg)

***Figure 25.2.** Simulation: the share of requests the dealer wins among five, against its pricing time, under three client rules, all dealers at the same markup. At expiry the curve is flat until the pricing time’s tail reaches the timer, at hundreds of milliseconds; under the other two rules every millisecond counts. Data: `fig_rfq.py`, `nw_rfq.curves()`.*

At its $20\,\mathrm{m}\mathrm{s}$ pricing stage, the dealer wins 19.2% of requests when clients take the best answer at expiry, 26.4% when they take the best of the first three, and 39.0% when they take the first acceptable answer: being faster than its four rivals is worth twice its share. The other side of the same rules is the business lost to speed: under “first acceptable”, 5.7% of all requests are ones where the dealer’s answer was the best acceptable one in time and a faster rival’s was taken; under “best of the first three”, 1.6%.

| Client rule | Win rate | Halving pricing to 10 ms | One cent better |
| --- | --- | --- | --- |
| Best at expiry | 19.2% | $+0.0$ points | $+0.9$ points |
| Best of first three | 26.4% | $+2.3$ points | $+1.0$ points |
| First acceptable | 39.0% | $+12.6$ points | $+0.9$ points |

***Table 25.1.** Simulation: what the dealer gains in win rate from halving its pricing time, against bidding one cent per 100 face (one basis point of price) better, under each client rule. Data: `nw_rfq.values()`.*

The value of a millisecond and the value of a basis point are therefore not comparable in general but only per rule ([Table 25.1](#tab-nw-fixed-income-and-rfq-platform-connectivity-value)). A dealer whose clients wait for the timer should spend on price; one whose clients execute the first acceptable answer should spend on its pipeline first, since ten milliseconds are worth nearly fifteen cents of price. Which rules its clients use is information the dealer can estimate from its own wins and losses by response time.

## 25.4 The interdealer order books

The interdealer markets in government bonds are central limit order books, run like exchanges and located in the same campuses as the futures and options markets of chapters 10 and 11 ([Box 25.2](#dat-nw-fixed-income-and-rfq-platform-connectivity-idb)). BrokerTec’s U.S. markets match in CME’s NY5 in Secaucus and its European markets in LD4.2 in Slough, each with a recovery site; BrokerTec Chicago, a second order book for the actively traded Treasuries, sits in CME’s Aurora data centre next to the Treasury futures, for trading cash against futures. On these books everything in chapters 1 to 9 applies: [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), feeds, gateways; the RFQ platforms’ seconds become microseconds again.

**As of September 2026 — Inter-dealer government bond order books on CME Globex, from CME’s documentation.**

BrokerTec US markets: production in NY5, recovery in Aurora; EU markets: production in LD4.2, recovery in NY5; recovery time objectives of four hours (US) and two hours (EU). BrokerTec Chicago (secondary U.S. Treasury actives order book): the CME Globex data centre in Aurora, Illinois.

The distance between NY5 and Aurora is the cash–futures basis trader’s distance: the U.S. Treasury futures match in Aurora, the primary cash book in Secaucus, and the two are chapter 10’s New Jersey–Chicago corridor apart, the route on which fibre and microwave race. A second cash book in Aurora puts both legs in one building for the firms that trade them together.

**Method 25.4 (Connecting a fixed income desk).**

1. List the platforms and books the desk trades; for each, the protocol, the session type, the timer or wire time, and the data centre.
2. Build the auto-responder as a pipeline with a latency budget per stage; measure the share sent to a person and that person’s times.
3. Estimate the clients’ execution rules from wins and losses by response time; spend on speed where rules reward it and on price where they do not.
4. Colocate for the order books as for any exchange; for cash against futures, choose between two sites and one.
5. Monitor timer misses, answers after the first $k$ , and wins lost to speed, per platform and per client.

## 25.5 Tutorial: two seconds to answer

**Goal.** Simulate an auto-responder’s pipeline, the timer, and three client rules on Book 11’s auction. **End state:** [Figure 25.2](#fig-nw-fixed-income-and-rfq-platform-connectivity-wins) and [Table 25.1](#tab-nw-fixed-income-and-rfq-platform-connectivity-value).

1. **Pipelines.** `firm_rfqlink.Pipeline` and `Stage` ; `response_ms` ( [Listing 25.1](#lst-nw-fixed-income-and-rfq-platform-connectivity-response) ) and `miss_prob` for the timer.
2. **Auction.** `auction` with each rule ( [Listing 25.2](#lst-nw-fixed-income-and-rfq-platform-connectivity-rules) ), checked against `firm_rfqmm.simulate` when every answer is in time.
3. **Value.** `value_of` for a faster pipeline and a better price; `nw_rfq.curves` across pricing times.

**What to change next.** Let each client choose its rule at random with shares estimated from data, and let the markup respond: Book 11’s equilibrium under a first-acceptable rule.

## 25.6 Build: the RFQ connectivity model

**Purpose.** Timers, pipelines and client rules for a dealer on RFQ platforms: the fixed income rows of chapter 29’s plan.

**Interface.** `firm_rfqlink`: `Stage`, `Pipeline`, `response_ms`, `miss_prob`, `auction`, `value_of`, `scaled`, `log_grid`.

**Rules.** Prices follow Book 11’s `firm.rfqmm` model, unchanged; pipeline and client parameters are stated assumptions; results are a labelled simulation.

**Acceptance tests.** `code/firm/rfqlink/tests/`: identity with `firm_rfqmm.simulate` when every answer is in time, deterministic pipelines and timers, and the rules’ ordering.

**Stretch.** Wire times and last look on streams; clients’ rule mix estimated from data; throttles on sessions.

Sources and further reading

- TW SEF LLC, Trading and Execution Protocols (2015).
- The TRADE, “Automating trade execution, intelligently” (2018); Markets Media on MarketAxess’s Adaptive Auto-X (2023).
- CME Group Client Systems Wiki: BrokerTec disaster recovery process and scenarios; BrokerTec Chicago.

## 25.7 Exercises

**Exercise 25.1 ★.**

What happens to an answer that arrives after the [quote timer](#def-nw-fixed-income-and-rfq-platform-connectivity-timer)?

**Solution of Exercise 25.1.**

It is not shown to the client: the dealer has no price in that auction, whatever it would have been.

**Exercise 25.2 ★.**

Where do BrokerTec’s U.S. and European order books match, and where do they recover?

**Solution of Exercise 25.2.**

U.S. markets in CME’s NY5 in Secaucus, recovering in Aurora; European markets in LD4.2 in Slough, recovering in NY5.

**Exercise 25.3 ★.**

Why is the chance of missing a two-second timer almost the share of requests sent to a person?

**Solution of Exercise 25.3.**

The automatic stages sum to tens of milliseconds and practically never reach two seconds; a person, at six seconds’ median, misses two seconds 98.6% of the time, so the chance is about $0.02 \times 0.986 = 1.97\%$, 1.94% in the simulation.

**Exercise 25.4 ★★.**

Using [Proposition 25.3](#prop-nw-fixed-income-and-rfq-platform-connectivity-speed), why does halving the pricing time gain nothing under “best at expiry”?

**Solution of Exercise 25.4.**

At expiry the client compares every answer received in time whatever its order; the dealer’s answers already arrive in time except the person’s, which a faster pricer does not change.

**Exercise 25.5 ★★.**

A client executes “at the best price once it has five responses” and asks five dealers. Which of the chapter’s rules is that?

**Solution of Exercise 25.5.**

With five dealers asked, the best of the first five is the best of all who answer in time, unless someone answers after the timer: it is “best at expiry”, except that execution happens as soon as the fifth answer arrives. With more dealers asked, it becomes “best of the first five”.

**Exercise 25.6 ★★.**

Why might a cash–futures basis trader prefer a second Treasury order book in Aurora?

**Solution of Exercise 25.6.**

Treasury futures match in Aurora; with a cash book there too, both legs of a basis trade are in one building, and the New Jersey–Chicago corridor’s milliseconds and its costs drop out of the trade.

**Exercise 25.7 ★★★.**

*Coding.* With `nw_rfq.curves`, at what pricing time does the dealer’s win rate under “first acceptable” fall below its rate under “best at expiry”?

**Solution of Exercise 25.7.**

At about $50\,\mathrm{m}\mathrm{s}$, the competitors’ own pricing time: 19.0% under “first acceptable” against 19.2% at expiry; faster than the competitors, “first acceptable” favours the dealer, slower, it penalises it.

**Exercise 25.8 ★★★.**

*Find the flaw.* “Our clients have two-second timers, so our 20-millisecond pricer is a hundred times faster than it needs to be.”

**Solution of Exercise 25.8.**

The timer is not the race when clients execute the first acceptable or the best of the first few answers: then the dealer races its competitors, whose pricers are tens of milliseconds, and ten milliseconds are worth nearly fifteen cents of price.

## 25.8 Problem: Two Seconds to Answer

**Problem 25.1.**

Weekend problem — timers, rules and a dealer’s pipeline

A dealer answers requests for quote on corporate bonds against four competitors. Its pipeline and theirs are the chapter’s; the timer is two seconds.

**Part I — The timer.**

1. What is the chance that the dealer misses the timer, and where does it come from?
2. What would it be fully automatic?
3. At what timer length does the fully automatic pipeline stop missing?
4. What does a missed answer cost the dealer, compared with a losing one?

**Part II — The rules.**

5. What share of requests does the dealer win under each rule?
6. What share is lost to speed under each?
7. Why is it zero at expiry?
8. Why does the dealer win more under “first acceptable” than at expiry?

**Part III — Speed against price.**

9. What does halving the pricing time gain under each rule?
10. What does bidding one cent better gain?
11. How many cents of price are ten milliseconds worth under “first acceptable”?
12. How would the dealer find out which rules its clients use?

**Part IV — The verdict.**

13. State the *named result* : the probability of missing the [quote timer](#def-nw-fixed-income-and-rfq-platform-connectivity-timer) at the pipeline’s latency distribution, and the share of business lost to a faster dealer under a first-acceptable execution rule.
14. Which inputs are published and which assumed?
15. Where should the dealer spend its next engineering month?
16. What happens if every competitor also halves its pricing time?
17. How should the share sent to a person be managed?
18. What changes on the inter-dealer order books?
19. Where does this go in chapter 29’s plan?
20. In one sentence: when does a millisecond matter on a platform whose timer is two seconds?

**Solution of Problem 25.1.**

**Part I.**

1. 1.94%, almost all from the 2% of requests answered by a person.
2. Zero at two seconds; 2.4% at a $100\,\mathrm{m}\mathrm{s}$ timer.
3. Above about half a second: the simulation finds 0.002% at $562\,\mathrm{m}\mathrm{s}$ and none from one second.
4. Both are no trade, but a missed answer also tells the client the dealer did not answer: a count against it in the client’s dealer rankings.

**Part II.**

1. 19.2% at expiry, 26.4% best of the first three, 39.0% first acceptable.
2. 0, 1.6% and 5.7% of requests.
3. At expiry every answer received in time is compared, so the best acceptable one is always chosen.
4. It is faster than its four rivals (20 against $50\,\mathrm{m}\mathrm{s}$ of pricing), so it is often the first acceptable answer.

**Part III.**

1. 0.0, 2.3 and 12.6 points.
2. 0.9, 1.0 and 0.9 points.
3. About fifteen (12.6 against 0.9 points a cent).
4. From its own history: wins and losses by its response time and its rank in arrival order, per client; a win rate that falls with rank at equal price reveals a rule other than expiry.

**Part IV.**

1. *Named result* : with a pipeline whose automatic stages take tens of milliseconds and 2% of requests answered by a person, the dealer misses 1.94% of two-second timers; under a first-acceptable rule it loses 5.7% of all requests to faster dealers despite the best acceptable price, and halving its pricing time gains 12.6 points of win rate against 0.9 for a cent of price.
2. Published: the platforms’ protocols and automation, the order books’ sites. Assumed: every pipeline number, the person’s share and times, the timer, the price model’s parameters, and the rules’ use.
3. On the pricing stage if its clients use first-acceptable or first- $k$ rules; on the share sent to a person if timers are short; on price if they wait for expiry.
4. The advantage disappears and the win rates return toward one in five; speed then protects share rather than winning it.
5. Reduce it by widening the auto-responder’s limits where the risk allows, and route the rest to a person with an alert and a deadline well inside the timer.
6. Everything: an order book is an exchange, with feeds, gateways and [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) , and microseconds matter again.
7. In the fixed income rows: platforms and sessions, the auto-responder’s latency budget, the person’s queue, and the order books’ sites and [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) .
8. When the client’s rule executes before the timer, on the first acceptable or the first few answers.

## 25.9 Interview questions

**Interview question 25.1 ★ developer.**

What are the stages of an RFQ auto-responder, and which one would you expect to be slowest?

**Solution of Interview question 25.1.**

Network in, FIX engine, request enrichment, pricing (fair value, curve, comparables, inventory), limits and risk, answer out. Pricing, if it recomputes a curve or waits for data; a person, if the request is outside the automatic limits.

*What the interviewer is looking for: Stages; the pricer’s variance; the manual path.*

**Interview question 25.2 ★★ trader.**

Why would a client execute the first acceptable answer rather than wait for the best?

**Solution of Interview question 25.2.**

To execute quickly while the market is still where it saw it, to reduce information leakage from a long auction, and because its own rules or workload call for automatic execution once the price is good enough.

*What the interviewer is looking for: Speed of execution; leakage; automation; the price tolerance.*

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

How would you estimate whether your response time costs you business on a platform?

**Solution of Interview question 25.3.**

Log each request’s arrival, the answer time, the rank in arrival order if the platform tells you, the price against the winning or cover price, and the outcome; model win probability on price and response time together, per client.

*What the interviewer is looking for: Joint model of price and time; per-client rules; the cover price.*

**Interview question 25.4 ★★ developer.**

Your auto-responder’s p99 latency doubled after a release. What do you check?

**Solution of Interview question 25.4.**

Per-stage latency to find the stage; the pricer’s data dependencies (a slow curve rebuild, a cache miss), garbage collection or allocation, logging, the FIX engine’s threads, and whether the share sent to a person changed.

*What the interviewer is looking for: Stage attribution; data dependencies; runtime effects; the manual share.*

**Interview question 25.5 ★★ researcher.**

Should a dealer quote tighter or answer faster? How would you decide?

**Solution of Interview question 25.5.**

It depends on the clients’ execution rules: estimate the marginal win rate of a cent of price and of a millisecond from the dealer’s own history, and weigh them against their costs: a cent is given away on every trade, a millisecond is paid for once.

*What the interviewer is looking for: Rules decide; marginal values; recurring against one-off costs.*

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

Design the connectivity and auto-responder for a dealer answering on three bond platforms and trading on an inter-dealer book.

**Solution of Interview question 25.6.**

FIX sessions to each platform with redundant lines; one pricing service with a latency budget and a fast path for liquid bonds; limits and risk in-line; a person’s queue with alerts; per-platform monitoring of misses, ranks and losses to speed; [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) and [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) for the order book in its data centre, with its own feed handlers and gateway.

*What the interviewer is looking for: Sessions; pipeline budget; manual path; monitoring; order book as an exchange.*