When I joined the trading firm straight out of university, I could write Java, profile a JVM, and argue about data structures. I had no idea how currency markets worked. My tech lead gave me one piece of advice: “Read everything you can about how the market actually works before you write any code. It’ll save you from building the wrong thing twice.”

This is what I wish someone had explained to me on day one.

The FX Market Structure

The foreign exchange market is decentralised — there’s no central exchange, no single order book, no canonical price. Instead, there’s a network of participants connected through bilateral relationships and electronic venues:

Tier 1 Banks (market makers)
  │  quote prices to each other on
  ▼
Interbank ECNs (EBS, Reuters Matching)
  │  aggregate into
  ▼
"Interbank market" — the reference rate
  │  banks re-quote to
  ▼
Second-tier banks / prime brokers
  │  who re-quote to
  ▼
Trading firms, hedge funds, corporates, retail

The price you see on any terminal is always one institution’s quote, not a universal price. EUR/USD at 1.2845 from Bank A may differ by 0.1–0.5 pips from Bank B’s quote for the same pair at the same instant. A trading firm’s job, in part, is to exploit those differences or to route orders to the best available price.

The Spot Trade Lifecycle

A spot trade is the simplest FX transaction: you buy or sell a fixed amount of currency for immediate delivery (two business days for most pairs).

1. Quote request (RFQ or streaming)
   Client → Dealer: "What's your price for EUR/USD?"
   Dealer → Client: "1.28445 / 1.28455" (bid/ask)

2. Order
   Client → Dealer: "I'll buy 10M EUR at 1.28455"

3. Execution
   Dealer: accept / reject / counter
   On accept: trade confirmed

4. Confirmation
   Both sides exchange SWIFT or FIX confirmations

5. Settlement (T+2)
   Clearing through correspondent banks
   USD delivered to EUR seller, EUR delivered to USD buyer

Steps 1–3 are what the trading systems handle in microseconds to milliseconds. Steps 4–5 happen in the back office and take hours to days.

The FIX Protocol and the Data Flow

The messaging layer between most professional participants is FIX (Financial Information eXchange). A FIX message is a pipe-delimited text format:

8=FIX.4.4|9=148|35=D|49=CLIENT|56=DEALER|
34=1234|52=20120321-10:44:23.456|
11=ORD-001|55=EUR/USD|54=1|38=10000000|
40=2|44=1.28455|59=0|10=089|

Decoded:

  • 35=D — message type: New Order Single
  • 55=EUR/USD — symbol
  • 54=1 — side: buy
  • 38=10000000 — quantity: 10 million
  • 40=2 — order type: limit
  • 44=1.28455 — price

The engineer’s job is to parse this stream (typically tens of thousands of messages per second) as fast as possible, route the right messages to the right handlers, and respond within the agreed SLA.

Price Feeds and What They Actually Contain

Market data from an ECN arrives as a stream of price updates. Each update contains:

Timestamp:  2012-03-21 10:44:23.456789
Pair:       EUR/USD
Bid:        1.28443
Ask:        1.28453
Bid size:   5,000,000 (5M EUR)
Ask size:   3,000,000
Venue:      EBS

The “size” tells you how much is available at that price. In liquid pairs like EUR/USD, liquidity is deep and prices are tight (0.5–1 pip spread). In illiquid pairs like USD/TRY, spreads can be 5–30 pips and sizes are smaller.

The engineering challenge: you receive updates for 50–100 currency pairs, potentially 10,000+ messages/second during active sessions, and you need to maintain a current “best price” view across multiple venues, apply validation, and distribute to consumers in under 1ms.

What “Execution” Means in Practice

An FX execution system doesn’t just route an order. It:

  1. Checks the price is still valid — the quote may be 50ms old; has it moved?
  2. Checks risk limits — does this trade exceed position limits, notional limits, or counterparty credit limits?
  3. Selects the venue — which bank/ECN currently has the best price that will accept this size?
  4. Manages partial fills — if no single venue has 10M available, can you split across venues?
  5. Handles rejections — the dealer may reject (price moved), requiring re-routing

Each of these steps adds latency. The HFT question is: which steps can be eliminated or parallelised without increasing risk?

The Concepts That Matter for Systems

Spread: the difference between bid and ask. This is the market maker’s revenue. A tighter spread means lower cost to trade. Engineering implication: if your price model uses mid-price (bid+ask)/2 but you execute at ask, your profitability model must account for the spread.

Slippage: the difference between the price you expected to trade at and the price you actually traded at. Caused by price moving between quote and execution, or by market impact (your order is large enough to move the price). Engineering implication: measure slippage on every trade and feed it back to pricing.

Latency arbitrage: if you receive a price update faster than another participant, you can trade on their stale quote. This is a central concern in HFT and a central reason that low latency matters at all.

Market impact: large orders move the price against you as the market absorbs them. A 100M EUR/USD order executed naïvely will push the price up as each tranche is filled. Execution algorithms (TWAP, VWAP, participation rate) manage this.

Understanding these concepts changed how I thought about every system I built at the firm. The data pipeline isn’t just a message router — it’s the foundation of a system that makes money or loses it based on how fast, accurately, and reliably it operates. That context makes the performance requirements feel less arbitrary.