Capital Markets

What this area actually covers

Capital markets software moves an instruction to buy or sell a security through to a record of ownership. That span is the whole subject. A portfolio manager or an algorithm decides to buy; a broker's order management system validates and routes the order; a venue matches it against a willing seller; the trade is confirmed, cleared, and settled when cash moves one way and the security the other. Every system you will be asked about sits on that line, and a good candidate says which part they built.

Two things get wrongly bundled in. Retail payments share vocabulary with settlement but have different regulators and failure modes. Quantitative research consumes the same data, but the skill is mathematical, and nobody hiring a trading systems engineer is testing your stochastic calculus.

A third confusion is worth naming early because it shapes how you read job adverts. "Trading systems" in common speech means the fast part at the front, but the great majority of employment in this domain is behind that: order management, enrichment, risk, allocation, confirmation, settlement instruction, reconciliation, reporting. The front end is where the vocabulary comes from. The back is where the headcount is.

The seven areas underneath

The subsections follow the path an instruction takes, with two cross-cutting areas — risk and execution algorithms — placed where they first bite. Read them in order the first time, because each one assumes the vocabulary of the one before it, and the classic domain mistake in interviews is describing a later stage in the language of an earlier one.

Order Lifecycle

This is the spine of the domain and the part every interview touches. It covers what an order is as a data structure, the order types and qualifiers a venue accepts, the validation a broker performs before anything leaves the building, routing to one venue or several, matching under price-time priority, and the stream of execution reports that reports progress back. The reason it exists as a separate area rather than being folded into "trading" is that an order is a long-lived stateful object with a legally significant history: every amendment, partial fill, cancel request and rejection is a fact that may be examined later. Open it for order types and time-in-force, for the difference between an order, an execution and a trade, and for the state transitions that trip people up, such as a cancel request racing a fill.

Market Data

Everything upstream of a decision runs on market data, and this is the subsection about consuming it correctly. A feed is a high-volume sequenced stream of incremental updates, usually multicast, and your view of the market is correct only if you have applied every message in order. So the material here is sequencing and gap detection, choosing between retransmission and rebuilding from a snapshot channel, arbitrating two redundant feeds arriving out of step, book building at level one, level two and full depth, conflation when a consumer cannot keep up, and the capture and replay infrastructure everything downstream depends on. It exists separately from the order lifecycle because the failure modes are entirely different: an order system fails loudly, a market data system fails by being quietly wrong. Open it for gap recovery strategy and for why capacity that is comfortable on average is not comfortable at the open.

Clearing & Settlement

Between a matched trade and a changed record of ownership sit two distinct processes that are constantly conflated. Clearing establishes what each party owes, manages the credit risk in the meantime, and in a centrally cleared market replaces the bilateral trade with two trades facing a central counterparty. Settlement is the actual exchange of securities for cash, on settlement date, through a central securities depository. This subsection covers novation, netting, the settlement cycle and its compression, delivery versus payment, and what happens when settlement fails — which is common enough to have its own machinery of penalties and buy-ins. Open it if you want the single most valuable concept in the domain, which is that a matched trade is a promise and nothing more.

Custody & Asset Servicing

Once settled, somebody has to hold the asset and look after it, and that somebody is usually a custodian rather than the investor. This subsection covers positions and holdings as distinct from trades, the difference between a trade-date and a settlement-date view of a position, safekeeping and the chain of custody through global and sub-custodians, and asset servicing: dividends, coupons, stock splits, rights issues, mergers, tender offers. Corporate actions get disproportionate attention here because they are disproportionately painful — they are announced in prose, interpreted by humans, dated by several competing dates, and they can land in the middle of an unsettled trade. Open it for the record-date and ex-date vocabulary, for mandatory versus voluntary events, and for reconciliation against the custodian's own record of what you hold.

Risk & Margin

Risk in this domain is not an abstraction; it is a set of gates in the order path and a set of numbers computed against a portfolio. Pre-trade, a broker must prevent orders that breach a client's credit limit, exceed a fat-finger threshold, or come from an algorithm that has lost control; in the United States, brokers offering market access are required to have such controls in place, and similar duties exist elsewhere. Post-trade, exposure is monitored in real time, and a central counterparty demands initial margin against potential future exposure plus variation margin as positions move. This subsection covers those gates, exposure and limit monitoring, margin methodology at the level an engineer needs, and the kill switch — the deliberate ability to stop everything, which is harder to build well than it sounds. Open it for what belongs in the hot path and what does not.

Post-trade Processing

This is the middle office, and it is where most of the domain's employment sits. A fund manager trades one large block and then allocates it across many underlying accounts; each allocation must be confirmed with the counterparty and affirmed by the client; standing settlement instructions must be attached; trades that do not match must be repaired by a human before a deadline. This subsection covers allocation, confirmation and affirmation as distinct steps, trade enrichment, the exception queues where mismatches land, and the workflow and deadlines that govern all of it. It exists separately because its constraint is a clock rather than a microsecond budget: everything here has a cut-off time, and settlement-cycle compression moved those cut-offs earlier. Open it for the step-by-step flow and for why "the trade broke" is a sentence with about a dozen distinct causes.

Execution & Algorithms

A large order cannot simply be sent to a venue, because doing so tells the market what you want and moves the price against you. This subsection covers the response: execution algorithms that slice a parent order into children over time or volume, smart order routing across fragmented venues, and transaction cost analysis that measures afterwards whether the execution was good. The vocabulary here — volume-weighted average price, time-weighted average price, percentage of volume, implementation shortfall, arrival price — names both the strategies and the benchmarks used to judge them. Open it for how a parent-child order model works in a system that must still report every child fill accurately, and for the governance obligations that attach to algorithms in regulated markets.

Where it sits in a real business

Four institutions own distinct pieces, and confusing them is the commonest domain mistake in interviews.

Novation is the idea to hold on to: once cleared, the original bilateral trade is legally replaced by two trades facing the CCP, so neither side carries the other's credit risk. That is why margin calls exist and why a CCP failure would be systemic — the concentration of risk is the price paid for removing it from the participants.

Walk the whole path once and the shape of the industry becomes obvious.

flowchart TD
  A[Decision to buy] --> B[Broker validates and applies pre-trade risk]
  B --> C[Order routed to a venue]
  C --> D[Matched against a resting order]
  D --> E[Execution reports back to the client]
  E --> F[Allocation, confirmation and affirmation]
  F --> G[Novation and netting at the clearing house]
  G --> H[Settlement against payment at the depository]
  H --> I[Custodian updates the holding]

The step to look at is the one from E to F, because that is where the clock changes. Everything above it is measured in microseconds or milliseconds and everything below it is measured against a cut-off time on a calendar, and almost every painful incident in this domain is an assumption from one side of that line meeting a constraint from the other.

Money and securities do not move at the same moment as the trade, and that gap is the source of most of the domain's machinery. Trade date is the day the trade is agreed; settlement date is the day ownership and money change hands. The gap keeps shrinking: the United States, Canada and Mexico moved to T+1 in May 2024, India completed its move in January 2023 and has since piloted optional same-day settlement, and the UK, EU and Switzerland have announced October 2027. What T+1 removed is slack. Affirmation, allocation, cross-border FX funding and stock-loan recalls that happened overnight now sit on the trade-date evening, so 2am batch jobs became time-critical and exception queues a human cleared next morning must clear in hours.

Settlement does not always happen. A seller who cannot deliver the security on time causes a settlement fail, which is routine rather than exotic, and markets build machinery to discourage it: cash penalties in some jurisdictions, buy-in procedures where the failing party is forced out of the position, and securities lending markets that exist largely so that deliverable stock can be borrowed to cover. When you hear that a post-trade team is firefighting, fails are usually what they are firefighting.

Value changes hands at three distinct moments, and it is worth being able to name them separately: at execution, where a price and an obligation are fixed; at clearing, where the obligation is novated and collateralised; and at settlement, where the asset and the cash actually move. A candidate who can place a given system at the right one of those three is already ahead of most.

The vocabulary of the first week

The word to be careful with is trade, which front office, middle office and back office each use to mean a slightly different object. To an execution system it is a fill; to the middle office it is an allocated, enriched and confirmed record; to settlement it is an instruction with a place and a date. When two teams disagree about a count of trades, this is almost always why.

Who does this work

Trading systems engineers write order gateways, matching engines and pre-trade risk checks, historically in C++ and Java with Rust appearing. Market data engineers own feed handlers, book builders and the historical capture everything downstream replays from. Post-trade engineers build confirmation, allocation, settlement instruction and reconciliation systems, which is less glamorous and at least as valuable. A day is rarely exotic: read a venue specification, reproduce a sequence gap from captured data, argue about whether a fill should be rejected or repaired. Business analysts here are unusually technical, turning specifications and reporting rules into requirements, and trade support staff live in the exception queues you produce.

Quantitative developers sit between research and production, turning a model or a strategy written for analysis into something that can run inside a risk and latency budget, and the job is mostly software engineering with enough mathematical literacy to avoid changing the meaning of what you are porting.

The front, middle and back office split predicts what a stakeholder cares about, and learning to hear which one is speaking is a genuine professional skill.

Most incidents are a front-office assumption meeting a back-office constraint: an order type used in a way the enrichment rules did not anticipate, a client account onboarded without standing settlement instructions, an amendment applied after a cut-off. None of those are technically difficult. All of them require knowing the process to prevent.

Demand, adoption and how that is changing

This is a narrower market than web or cloud engineering, concentrated in a handful of cities and a predictable set of employers: exchanges, brokers and banks, proprietary trading and market-making firms, asset managers, and the vendor platforms most of the industry runs on. It pays for depth rather than breadth, because a defect costs a regulatory finding or an unhedged position.

Three concrete forces drive current demand rather than general growth. Settlement-cycle compression created a multi-year post-trade remediation programme at every firm with cross-border flow, and the 2027 UK and EU move keeps it alive. Reporting and surveillance duties — transaction reporting, clock synchronisation and algorithm governance under MiFID II, consolidated audit trail reporting in the US — are permanent commitments, not projects; they require the firm to be able to reconstruct precisely what happened and when, which is a data engineering problem that never finishes. And market data has become a serious cost line, funding work on entitlements, conflation and cheaper capture.

There is a slower structural shift underneath those. Post-trade infrastructure at many firms is old, batch-shaped and built for a world with more overnight slack than currently exists, so the modernisation work is real and long-lived: turning overnight processes into intraday ones, replacing file transfer with messaging, and adopting ISO 20022 message formats where the older proprietary ones no longer carry enough structure. That is unglamorous work with a decade of runway in it.

Honestly, though: the ultra-low-latency arms race employs very few people, much of the sell side runs vendor platforms where the work is configuration rather than green-field design, and roles cluster geographically. Without access to a market centre, the realistic entry points are a vendor, a captive technology centre, or post-trade. The captive centres are worth taking seriously as a route, because they carry genuine ownership of production systems even where they do not carry the front-office glamour.

What makes it hard

The matching engine is conceptually simple and unforgiving. A continuous limit order book under price-time priority is a sorted set of price levels, each holding a FIFO queue of resting orders: better prices match first, and within a price level the earlier arrival fills first. That rule is why latency matters at all — queue position is worth money. Order types layer on top: a market order takes whatever is there, a limit order sets a worst acceptable price, stop orders activate on a trigger, and time-in-force qualifiers such as immediate-or-cancel, fill-or-kill and good-till-cancelled decide the fate of an unfilled remainder. Price-time priority is not universal — some futures markets allocate pro-rata by size, and opening and closing auctions compute a single clearing price instead of matching continuously.

An order is also a state machine, and the awkward transitions are where bugs live.

stateDiagram-v2
  [*] --> PendingNew
  PendingNew --> New: venue acknowledges
  PendingNew --> Rejected: validation fails
  New --> PartiallyFilled: some quantity trades
  PartiallyFilled --> Filled: remainder trades
  New --> PendingCancel: cancel requested
  PendingCancel --> Cancelled: venue confirms
  PendingCancel --> Filled: fill won the race
  Filled --> [*]

The transition worth staring at is PendingCancel to Filled. A cancel request and an incoming fill can cross on the wire, the venue is the only authority on which happened first, and a client system that has already told a trader the order was cancelled now has a position it did not expect. Every trading system has to decide what it displays during that window.

Market data is where engineers underestimate the problem. A feed is a high-volume, sequenced, usually multicast stream of incremental updates, and your book is correct only if you applied every message in order. So you detect gaps from sequence numbers, choose between requesting a retransmission and rebuilding from a snapshot channel, reconcile two redundant feeds arriving out of step, and never fall behind — falling behind turns a small gap into a large one. Capacity that is fine on average is not fine at the open, at the close, or when a macroeconomic figure prints.

Determinism shapes the architecture. If a matching or risk engine is deterministic — same input sequence, same output, every time — you can replay a captured session to reproduce a bug, prove to a regulator what the system did, and fail over to a replica fed the same stream. Hence patterns that look old-fashioned: one sequenced input stream, a single writer, no allocation on the hot path, and an immutable log of everything received and sent. Auditability is not bolted on later; it is why the log is the primary data structure.

FIX, the Financial Information eXchange protocol, is the lingua franca for order flow: a session of tag=value messages with sequence numbers and heartbeats, in which a NewOrderSingle is answered by a stream of ExecutionReport messages covering acknowledgement, partial fills, fills, cancels and rejects.

sequenceDiagram
  participant C as Client
  participant OMS as Broker OMS
  participant R as Risk checks
  participant V as Venue
  C->>OMS: NewOrderSingle
  OMS->>R: Limit and fat-finger checks
  R-->>OMS: Pass
  OMS->>V: Order entry
  V-->>OMS: ExecutionReport New
  V-->>OMS: ExecutionReport PartialFill
  OMS-->>C: Both reports, in order

Notice that the risk check sits inside the path rather than beside it. It is synchronous, it is on the latency budget, and it cannot be skipped when the system is busy — which is exactly when a runaway algorithm is most likely to need stopping.

FIX is stateful, so sequence-number recovery and resend logic is real work, and every counterparty has its own dialect of custom tags, so "we speak FIX" never means two systems simply connect. Venues often use tighter binary protocols for their own market data and order entry, and post-trade messaging increasingly uses ISO 20022.

The last difficulty is the calendar, and it is the one nobody warns you about. Instruments settle on different cycles in different markets, holidays differ by venue and by currency, corporate actions have their own dated sequence, and a system that models "a day" as twenty-four hours in one time zone will be wrong within a month. Reference data — the descriptions of instruments, calendars, counterparties and accounts that everything else joins against — is quietly one of the largest sources of production defects in the domain, precisely because it is nobody's exciting project.

Why study it

Study it if you like a hard correctness bar and a real clock: systems where the specification is written down, the failure is observable, and being right matters more than shipping weekly. The knowledge compounds unusually well, because instruments and venues change but the order-to-settlement skeleton has been stable for decades, and an engineer who understands that skeleton is employable across the whole industry rather than at one firm.

It is also one of the few commercial settings where the engineering practices that textbooks recommend are actually used, because the economics justify them: deterministic replay, immutable logs, exhaustive reconciliation, capture of every input. If you have ever wanted to work somewhere that takes correctness seriously rather than aspirationally, this is one of the places that does.

Do not study it because it sounds prestigious, or because you want to trade — that is a different career. If you want the fastest route to a well-paid engineering job, general backend or cloud work has far more openings and far less geographic constraint, and if regulated environments or being paged about a settlement break sound intolerable, the salary will not fix that.

Your first hour

Build a limit order book. In any language, define an order as (id, side, price, quantity, timestamp), keep two price-indexed collections of FIFO queues, and implement three operations: submit a limit order that rests or matches against the opposite side, cancel by id, and print the top of book. Then hand-write a tape and replay it:

1  BUY  100 @ 10.00
2  SELL  50 @ 10.10
3  BUY   80 @ 10.10      -> matches 50 against order 2, 30 rests at 10.10
4  SELL 120 @ 10.00      -> matches 30 against order 3, then 90 against order 1

The artefact is a fill log with the right counterparty order ids and quantities plus the closing book state. If order 4 fills against order 1 before order 3, you have no price priority; if two orders rest at the same price and the later one fills first, you have no time priority. Then replay the same tape twice and check the log is byte-identical — that is determinism, the property the rest of the domain depends on.

If you have time left, extend the exercise past execution, because that is where the domain actually lives. Take the fills you just produced and write out what must happen next:

Fill      SELL 120 @ 10.00 executed as 30 @ 10.10 and 90 @ 10.00
Allocate  30 to fund A, 90 to fund B, at the average price or per fill?
Confirm   send each allocation to the counterparty
Affirm    counterparty agrees, or it lands in a break queue
Net       one net obligation per instrument per settlement date
Settle    deliver 120 shares against cash on settlement date

The question in the second line is a real one with real consequences and no universally correct answer, and noticing that you have to decide it is worth more than the order book you just wrote.

What this is not

It is not high-frequency trading. HFT is one small, extreme corner; most capital markets engineering is order management, market data, risk and post-trade, where correctness dominates and microseconds do not.

Clearing is not settlement. Clearing establishes obligations and manages credit risk between the trade and its completion; settlement is the actual exchange of securities for cash, so a cleared trade has delivered nothing yet. Relatedly, a broker is not a custodian and a matched trade is not an owned asset. Candidates often describe an "order hits the exchange and then you own the share" model, which skips novation, netting, the depository, and the whole reason settlement failures exist.

It is not quantitative finance, and the two are hired through different pipelines with different interviews. Building the system that a strategy runs on and designing the strategy are separate crafts, and firms that blur them in job adverts usually mean the former.

Nor is it a domain you can finish learning by reading. The lifecycle is in books, but knowing which exception queue fills when a corporate action lands mid-settlement comes from having been on the rota.

Ownership does not change when the trade matches; it changes on settlement date, and almost every hard problem in this domain lives in the gap between the two.