Capital markets fundamentals

The shape of the entity you are storing and the arithmetic you are allowed to do with it. An equity is close to a simple thing: one identifier, one quantity, one price, and a corporate-action feed that occasionally rewrites history. A bond has accrued interest, a day-count convention and a price quoted as a percentage of face value, so a naive quantity x price is wrong. A derivative has an underlying, an expiry and a contract multiplier, so its economic exposure is not its notional. Candidates who say "an instrument is an instrument" have usually only built equity systems, and the follow-up question is always about the one that does not fit their model.

Equities trade on visible order books with a last traded price, so valuation and position keeping are mostly bookkeeping. Fixed income is largely dealer quoted rather than exchange traded, so there may be no last trade for days, and price comes from a quote, a curve or an evaluated mark supplied by a vendor. Bonds also carry accrued interest between coupon dates, so the invoice price differs from the quoted price, and the same bond has a yield, a spread and a duration that all describe its price. The engineering consequence is that a fixed-income system needs a valuation dependency and a business-date calendar where an equity system needed neither.

Every FX trade is two currencies, so there is no single quantity — there is an amount in each leg and a rate relating them, and which one you consider the notional is a convention you must record rather than infer. Settlement is two payments in two national systems in two time zones, which is where the classic settlement risk lives: you pay before you are paid. It also trades nearly around the clock rather than in an exchange session, so "end of day" is a policy decision rather than a fact, and any system that assumed a daily close will need one chosen for it. Spot, forward and swap are distinct products sharing a pair.

A reference to something else, and a life with dates in it. A future or option points at an underlying, has an expiry, a contract multiplier and — for options — a strike and an exercise style, so the position is an exposure rather than a holding. That means valuation requires a model and inputs rather than a price lookup, risk is expressed as sensitivities rather than as market value, and the instrument itself expires, which is a scheduled event your system must handle rather than an exception. Over-the-counter derivatives add a bilateral contract with its own collateral terms, so the counterparty becomes part of the instrument's identity.

One company's ordinary shares, listed in one market, as the reference data actually arrives.

Instrument: a large UK-listed company, ordinary shares, London

  ISIN     GB00B03MLX29    12 chars, country prefix + national number + checksum
                           Identifies the SECURITY, not where it trades
  SEDOL    B03MLX2         7 chars, UK/Ireland numbering agency
                           Assigned per line of stock per market
  CUSIP    -               US/Canada scheme; a UK line may have none
  FIGI     BBG000C05BD1    12 chars, open scheme, share class and
                           venue-level variants both exist
  RIC      RDSA.L          Vendor ticker + venue suffix, changes when a
                           vendor reorganises or the listing moves
  MIC      XLON            The venue itself, ISO 10383

The trap is in the third column. An ISIN identifies the security but not the venue, so one ISIN can span several listings with different currencies, trading hours and settlement locations — which means an ISIN is not a sufficient key for a trade, a position or a market data subscription. A SEDOL is closer to what a trading system needs because it is per market, and that is exactly why firms end up keying on it and then failing on instruments outside its coverage.

Two of these are not stable, and that is the part people design around too late. A RIC is a vendor's ticker and changes when the vendor reorganises coverage or the company changes its listing, so anything persisted with a RIC as the key silently detaches from history. Tickers are worse: they are reused, so the same ticker means different companies at different times. The block above is itself an illustration of the point — those particular codes were retired when the issuer unified its share classes in 2022, so a system that pinned them a few years ago is now holding identifiers that resolve to nothing.

The practical rule is that your internal instrument identifier is your own opaque key, every external scheme is an alias with a validity period attached, and no external identifier is ever a primary key. That single decision is the difference between a reference data system you can extend and one that has to be rebuilt when the firm enters a second market.

Because the mapping is many-to-many, time-varying and contested. One security has several schemes, one scheme has several codes per security across venues and share classes, codes are reissued and retired, and two vendors will disagree about the same mapping on the same day. So the master is not a table of equivalences but a versioned record with sources, precedence rules and effective dates, plus a workflow for a human to resolve conflicts. The failure mode is quiet: a trade booked against the wrong line of stock reconciles against nothing, and the break surfaces days later in a settlement queue rather than as an error at the point of entry.

A two-for-one share split, and what it does to data that was already correct.

Before the split, on 2026-07-24
  Position   1,000 shares          Price 42.00       Market value 42,000
  Price series ... 41.20  41.75  42.00

Split effective 2026-07-27, ratio 2:1

After
  Position   2,000 shares          Price 21.00       Market value 42,000

What breaks if nothing else changes:

  Return series   42.00 -> 21.00 reads as a -50% day. It was a 0% day.
  Moving averages Every window spanning the date is meaningless
  Order in flight A GTC buy limit at 41.50 was near the market; it is now
                  20.50 above it and will fill instantly on the open
  Stop loss       A sell stop at 40.00 is now 19.00 above the market and
                  therefore already breached, so it fires on the open and
                  liquidates a position nobody asked to close
  Reconciliation  Custodian says 2,000, your book says 1,000, until the
                  entitlement is booked

The value is unchanged and every derived number is wrong. That is the whole problem with corporate actions: they are not price moves, they are redefinitions of the unit, so any series compared across the event has to be adjusted rather than read.

The standard answer is to keep two price series — the traded price as it happened, and an adjusted series carrying a cumulative adjustment factor — and to be explicit about which one every consumer reads. Regulatory reporting and trade reconstruction need the unadjusted price, because that is what actually traded. Analytics, backtests and charts need the adjusted one. Systems that keep only one are wrong for half their consumers.

The dates are the second half of the answer, and they are where the real mistakes are. An action has an announcement date, an ex date, a record date and a payment date, and they are not the same day; entitlement follows the record date while the price adjusts on the ex date. Combine that with an unsettled trade straddling the record date and the question of who is entitled becomes a genuine dispute that a claims process exists to resolve.

Voluntary actions are worse than mandatory ones because they need a decision. A tender offer or a rights issue has an election deadline, a default if nobody responds, and a client who must be contacted, so the system owns a workflow with a clock rather than a transformation.

Because almost every date in the domain is a business date in a specific market and currency rather than a calendar date. Settlement date is trade date plus a number of business days for the relevant market, coupon dates roll according to a convention when they fall on a holiday, and a currency leg can settle on a day the security's market is closed. Different venues, depositories and currencies have different holiday sets, so there is no single calendar — there are dozens, joined per instrument and per leg. Systems that compute dates by adding twenty-four-hour increments in one time zone produce wrong settlement dates within a month of going live, and the resulting breaks are tedious to trace.

The venue's record of resting interest: every unexecuted limit order, organised into price levels on each side, with the best bid and best offer at the top. It is both a data structure and a public artefact, because the aggregated levels are what the market data feed publishes and what everyone else's trading decisions are made from. Its central property is that it is a queue as well as a sorted collection, since orders at the same price are ranked by arrival, so a resting order has a position that has value. Understanding that queue position is economically meaningful is what makes the latency conversation make sense.

The rule is better price first, and within a price level earlier arrival first. Watch the order in which the resting orders are consumed.

Book before, with arrival times

  ASK  10.03   400   (A4 09:31:10)
       10.02   300   (A2 09:30:02)  200  (A3 09:30:40)
  ---------------------------------------------------
  BID  10.01   500   (B1 09:29:55)
       10.00   900   (B7 09:28:11)

Incoming: BUY 800 @ 10.03, a limit order

  fill 1   300 @ 10.02  against A2   best price, earliest at that level
  fill 2   200 @ 10.02  against A3   same price, later arrival
  fill 3   300 @ 10.03  against A4   next price level, partial

Book after

  ASK  10.03   100   (A4, remainder)
  ---------------------------------------------------
  BID  10.01   500   (B1)

Three readings. The buyer paid two prices for one order, so a single order produces several fills at several prices and the client's average price is a derived number — which is why any system that stores one price per order is already wrong. Reporting the fills individually and the average separately is the correct model.

A3 filled only because A2 was fully consumed, and that is the entire economic argument for latency. A3 arrived thirty-eight seconds later and was second in the queue at the same price; had the incoming order been for 300, A3 would have received nothing while quoting the same price and taking the same risk. Queue position is the product being bought with microseconds.

Price-time priority is not universal, and saying so is a strong signal. Several futures markets allocate pro rata by size within a level, which changes the incentive from being fast to being large, and opening and closing auctions do not match continuously at all — they collect interest and compute one clearing price that maximises executed volume. A candidate who assumes continuous price-time everywhere will design a fill allocator that is wrong on those venues.

Quote both sides continuously, so that someone wanting to trade can, and earn the spread between the two quotes in exchange for holding inventory it did not want. The position risk is the real business: having bought at the bid, the maker is long until it can sell, and the price can move against it in between. That is why quotes widen when volatility rises or when the maker's inventory is already skewed — the spread is compensation for risk, not a fee. Many venues formalise this with obligations to quote a minimum size for a minimum proportion of the session in return for reduced fees, which is what "designated" or "registered" market maker means.

The cost of immediacy. The bid is what you can sell at now and the offer is what you can buy at now, so the gap is what a round trip costs before any commission, and it widens with uncertainty and narrows with competition and volume. Two refinements matter in an interview. The quoted spread applies only to the size displayed at the top of the book, so a large order does not get it. And the mid price, the average of the two, is a convenient reference that nobody can actually trade at — using it as an execution price in a simulation is the most common way a backtest lies to you.

Slippage is the difference between the price you expected when you decided and the price you actually achieved, and it has several distinct components rather than one. Crossing the spread is the first and the smallest. Walking the book — consuming several levels because your size exceeded the top — is the second, and grows with order size. Market movement between decision and execution is the third, and can go either way. Market impact, where your own trading moves the price against you because others infer your intention, is the fourth and the reason execution algorithms exist. Naming those separately is the answer; saying "slippage is when you get a worse price" is not.

Because regulation deliberately opened share trading to competing venues, so the same instrument now trades on a primary exchange, several alternative venues and various non-displayed pools, each with its own fee schedule, order types and latency. The consequence for a broker is that the best price is a moving question rather than a fixed one, so it must consolidate quotes across venues, decide where to send each slice, and be able to demonstrate afterwards that the choice served the client. Fragmentation is therefore the reason smart order routing, consolidated market data and best execution monitoring all exist, and it is the reason connectivity and market data costs scale with the number of venues rather than with volume.

A period in which orders are collected without matching, followed by the calculation of a single price at which the greatest volume can trade, with everyone who participates receiving that price. Venues run them at the open and the close because continuous trading works badly when there is no established price and when a large amount of interest wants the same moment, and the closing auction in particular has become the largest single liquidity event of the day because index funds must trade at the official close. Engineering consequence: your system needs a session model, because order types, cancellation rules and data semantics differ inside an auction, and the volume spike is when capacity planning is actually tested.

A limit order specifies the worst price you will accept, so it controls price and risks not executing. A market order specifies no price, so it executes against whatever is resting, controlling certainty and risking a bad fill if the book is thin — which is why many venues convert them internally to aggressively priced limit orders and why some do not accept them at all. A stop order is dormant until the market reaches a trigger price, at which point it becomes a market or limit order; it is a conditional instruction rather than a resting one, so it is invisible to the book and provides no liquidity while it waits.

The fate of the unfilled remainder, which is the part candidates skip. A day order rests until the session ends and is then cancelled by the venue. An immediate-or-cancel order takes whatever is immediately available and cancels the rest, so partial fills are expected. A fill-or-kill order must execute in full immediately or not at all, so there is no partial fill — and confusing it with IOC is a common error. Good-till-cancelled rests across sessions, which is the one with real system consequences: it must survive a restart, be re-registered with the venue after a session break, and be reviewed against corporate actions that change the price it was pegged to.

Every arrow is somebody's decision, and knowing whose is the point of the diagram.

flowchart TD
    A[Client sends new order] --> B[Pending new<br/>broker validating]
    B -->|broker rejects on risk| R[Rejected]
    B -->|venue acknowledges| N[New and resting]
    N -->|venue matches part| P[Partially filled]
    P -->|venue matches remainder| F[Filled]
    N -->|client requests cancel| C[Pending cancel]
    C -->|venue confirms| X[Cancelled]
    C -->|fill won the race| F

The ownership split is the answer. The client owns only the requests — new, cancel, amend — and owns nothing else. The broker owns rejection on its own risk checks and nothing about execution. The venue owns every other transition, and its message is the only authority: a fill exists because an execution report says so, not because your system computed that it should have happened.

The transition to stare at is pending cancel to filled. A cancel request and an incoming fill can cross on the wire, and the venue decides which happened first, so a client system that optimistically showed the order as cancelled now has a position the trader did not expect. The design question is what you display during that window, and the defensible answer is a distinct pending state rather than either optimistic outcome.

Two more details separate people who have built this. Rejected and cancelled are different terminal states with different meanings — one says the order never existed at the venue, the other says it did and no longer does — and collapsing them loses information a regulator may ask for. And an amend is usually implemented as cancel-replace, so it has the same race and can leave you with neither the old order nor the new one if the cancel succeeds and the replace is rejected.

An order is an instruction with a state and a history. An execution, or fill, is one matched quantity against that order, and there may be many of them at different prices. A trade is the resulting bilateral obligation that will be cleared and settled, and in a block-and-allocate workflow one trade can become many allocated trades facing different accounts. The three are counted differently by different teams, which is why "how many trades did we do" is an ambiguous question inside a bank. Keeping the three as distinct entities with explicit links, rather than overloading one record, is what makes the reconciliation between front and back office possible.

A parent order is the client's actual intention — buy two million shares — and child orders are the slices an algorithm sends to venues to achieve it. The relationship must be explicit in the data model because reporting happens at both levels: the client is told about the parent's average price and progress, while every child fill is a separate executed quantity that must be reported accurately and audited individually. The complications are that children can be cancelled, rejected or partially filled independently, that the parent's remaining quantity must stay consistent with the sum of its children under concurrency, and that a cancel of the parent must chase children already in flight at several venues.

Spreading a large order over time so that it does not announce itself. A TWAP algorithm slices evenly across a time window, which is simple and predictable — and predictable is a weakness, because others can detect the pattern. A VWAP algorithm distributes the slices in proportion to expected volume, trading more when the market is busy, using a historical volume profile that is typically U-shaped across the day. Both are benchmarked against the metric they are named after, which is the important subtlety: a VWAP algorithm's success is measured against the market's realised volume-weighted price, so it is trying to be average rather than good, and that is exactly what some clients want.

It displays a small visible quantity while keeping a larger hidden reserve at the same price, so the book understates the interest resting there. What leaks is the refill: when the visible slice is consumed and another appears immediately at the same price, an observer can infer a reserve and infer its rough size by repeating the probe. That is why venues randomise the displayed quantity and why detecting icebergs is itself a strategy. For a system builder the point is that hidden quantity means the book you rebuilt from public data is not the book the matching engine has, so your fill predictions will be systematically wrong.

A rejection can come from the broker's own validation, from the venue's, or from a downstream risk check, and the three have completely different remedies. A broker rejection for a credit limit needs a limit change or a smaller order; a venue rejection for a price outside the permitted band needs a repriced order; a malformed message rejection needs a code fix. So the reject reason must be captured and surfaced rather than mapped into a generic failure, because a trader seeing "order rejected" with no cause will simply resend it, which is how a single bad order becomes a burst of them. Reject rates by reason are also one of the more useful health metrics a trading system has.

The Financial Information eXchange protocol, the industry's standard for order flow between counterparties. It is a session protocol as much as a message format: a long-lived connection with heartbeats, monotonically increasing sequence numbers in each direction, and a resend mechanism, so both sides maintain state and a reconnect is a negotiation rather than a fresh start. Messages are tag-equals-value pairs separated by a delimiter, which is self-describing and verbose, so venues often use tighter binary protocols for their own order entry and market data while FIX carries client flow. The session state is where the real work is, not the parsing.

A single order to buy shares, with the delimiter shown as a pipe for readability.

8=FIX.4.4|9=181|35=D|49=CLIENTA|56=BROKERB|34=1425|52=20260727-09:31:04.221|
11=ORD-000871|55=VOD.L|48=GB00BH4HKS39|22=4|54=1|38=50000|40=2|44=72.35|
59=0|60=20260727-09:31:04.219|1=FUND-17|207=XLON|10=094|

8    BeginString     protocol version, always first
9    BodyLength      byte count, always second
35   MsgType         D = NewOrderSingle
49   SenderCompID    who is sending
56   TargetCompID    who is receiving
34   MsgSeqNum       session sequence number, must not gap
52   SendingTime     when the sender sent it
11   ClOrdID         the CLIENT's id, unique per order, the correlation key
55   Symbol          human ticker
48   SecurityID      the real identifier
22   SecurityIDSource 4 = ISIN, so tag 48 is interpretable
54   Side            1 = buy, 2 = sell
38   OrderQty        quantity
40   OrdType         2 = limit
44   Price           limit price, required because OrdType is 2
59   TimeInForce     0 = day
60   TransactTime    when the decision was made, not when sent
1    Account         which account this is for
207  SecurityExchange venue
10   CheckSum        always last; the value shown is illustrative rather
                     than computed over these bytes

Three things in here are load-bearing. Tag 11, the ClOrdID, is assigned by the client and is how every subsequent execution report is correlated back to this order, so it must be unique per session and stable — a duplicate is a rejection and a reused one is a reconciliation nightmare. Tag 48 is meaningless without tag 22, which is the identifier scheme, and hardcoding an assumption about the scheme is a classic onboarding bug.

Tags 52 and 60 are different times and candidates conflate them. SendingTime is when this message left, TransactTime is when the underlying decision or event occurred, and for regulatory reconstruction it is the second that matters. A system that copies one into the other has destroyed the evidence it will later be asked for.

The absent field is the point worth making unprompted: there is no order state in this message. State lives in the stream of ExecutionReport messages coming back, each carrying the order status, the filled quantity so far and the remaining quantity, and the client's view of its own order is a projection of those. Every counterparty also adds custom tags above 5000, which is why FIX certification against each venue is a real project rather than a configuration change.

Tick to trade is the time from a market data packet arriving at your network card to an order leaving it. Broken down, the surprise is how little of it is your code.

Budget for a competitive, but not extreme, system

  network in, wire to NIC                          0.5 us
  kernel bypass receive into user space            1.0 us
  feed decode and book update                      1.5 us
  strategy decision                                0.8 us
  pre-trade risk checks, in path                   1.2 us
  order encode                                     0.7 us
  kernel bypass send                               1.0 us
  NIC to wire                                      0.5 us
  ------------------------------------------------------
  tick to trade                                    7.2 us

For contrast, typical orders of magnitude in the same units
  a single cache miss to main memory              ~0.1 us
  a Java garbage collection pause, young gen    ~1,000 us
  a context switch                                ~2-5 us
  one-way fibre, London to Frankfurt            ~2,800 us

The bottom block is the actual lesson. Your entire budget is a fraction of one minor GC pause, which is why these systems pre-allocate everything, avoid garbage on the hot path, and are measured in worst case rather than average — a mean of seven microseconds with a 99.9th percentile of two milliseconds is a system that is fast except when it matters.

Distance dominates everything you can do in software. If the venue is in Frankfurt and you are in London, no amount of optimisation recovers the 2.8 milliseconds of fibre, which is the entire commercial argument for colocation and the reason the latency conversation is usually about physical placement first and code second.

Two of these lines are policy rather than engineering. Kernel bypass exists because the general-purpose network stack costs more than the whole rest of the path, and pre-trade risk is deliberately kept inside the budget rather than moved beside it, because a check that can be skipped when the system is busy is a check that is absent exactly when a runaway algorithm needs stopping. Candidates who propose making risk asynchronous to save a microsecond have failed the question.

Physical proximity, which is the only way to reduce propagation delay. Renting space in the venue's own data centre removes the wide-area round trip and puts you in the same building as the matching engine, with cross-connect cabling of known and equalised length. Venues sell it as a product and equalise cable lengths between cabinets precisely because the alternative would be a fairness complaint. What it does not buy is a good system: colocation removes the distance, after which your own software's jitter is the entire remaining variable, and a poorly written colocated system loses to a well-written one in the same room.

The router's job is to fill a slice at the best achievable terms across venues that all publish different books.

flowchart TD
    S[Child order to route] --> B[Build consolidated view<br/>of top of book per venue]
    B --> C[Rank venues by price<br/>then displayed size]
    C --> D[Subtract fees and rebates<br/>to get net price]
    D --> E[Split the slice across venues<br/>and send simultaneously]
    E --> F[Collect fills and rejects]
    F --> G[Reroute the unfilled remainder<br/>on the refreshed book]

The step candidates omit is the fee adjustment. Venues charge takers and often rebate makers, and the difference is large enough that the venue showing the best displayed price can be the worse net outcome — so routing on price alone is both commercially wrong and hard to defend as best execution.

The interesting failure is in the last two steps. Your consolidated view is already stale by the time the orders arrive, so quotes you routed to may have gone, producing partial fills and rejects rather than the clean split you planned. Worse, sending to several venues simultaneously can execute more in total than you intended if a venue is slow to acknowledge, so the router needs its own accounting of in-flight quantity per child, not just per parent.

The second-order effect is information leakage. Spraying a slice across every venue tells several counterparties simultaneously that a buyer is present, and the price can move before the later legs arrive. That tension — reach more liquidity or reveal less intent — is the actual design problem, and it is why routers are tuned per client and per instrument rather than being one algorithm.

Because determinism is what makes replay possible, and replay is how you debug, prove and fail over. If the engine produces identical output from an identical input sequence, then a captured session can be re-run to reproduce a defect that occurred once at the open, a regulator's question about what the system did can be answered by re-running the day, and a hot standby fed the same sequenced stream will be in the same state as the primary without needing to replicate state. This is why the architecture looks old-fashioned — one sequenced input, a single writer, no reliance on wall-clock time or thread scheduling — and why an immutable log of everything received and sent is the primary data structure rather than an audit feature.

The checks are a small set of hard limits evaluated in the order path, and the rejection must be specific enough to act on.

Client FUND-17, limits in force

  max order value                   2,000,000 GBP
  max order quantity                  100,000 shares
  max order as % of 20-day ADV             5 %
  price collar vs last trade             ±10 %
  max net long position, this name  5,000,000 GBP
  daily gross traded value         25,000,000 GBP
  restricted list                   instrument must not be on it

Incoming: BUY 400,000 VOD.L @ 79.90, last trade 72.35

  order value        400,000 x 0.7990 = 319,600      PASS
  order quantity     400,000 > 100,000              FAIL
  % of ADV           400,000 / 6,100,000 = 6.6%     FAIL
  price collar       79.90 vs 72.35 = +10.4%        FAIL
  net long after     2,910,000 + 319,600            PASS
  daily gross        18,400,000 + 319,600           PASS
  restricted list    not present                    PASS

Reject: 35=8 39=8 103=99 58=QTY_LIMIT,ADV_LIMIT,PRICE_COLLAR

The design point is that these are cheap, absolute and in the synchronous path. Every one is a comparison against a number held in memory, deliberately so, because a check requiring a database call or a service hop would have to be skipped under load — and load is when a malfunctioning algorithm is most likely to be firing.

Reporting all three failures rather than the first is a deliberate choice. A trader who fixes the quantity and resubmits into a price collar rejection will resubmit again, and each cycle is more messages at a moment when the system is already unhappy. Returning the full set costs nothing and converts three round trips into one.

The limits themselves are a mixture of two different intentions and it is worth saying so. Order value, quantity and the price collar are fat-finger checks: they catch a mistyped order that no legitimate strategy would send. Position and daily gross limits are credit and mandate checks: they are about how much this client is permitted to do in total, and they need to be updated by fills as the day progresses, which makes them stateful and therefore the harder half to get right under concurrency.

The check nobody mentions is the message rate limit per session, which is what actually stops a looping algorithm, since a runaway sending one valid small order per microsecond passes every limit above until the position check catches up.

The deliberate ability to stop a trading system immediately: block new orders, cancel everything resting, and drop the sessions. It is hard because stopping badly is also dangerous. Cancelling every resting order leaves a hedged book suddenly unhedged, so the correct behaviour may be to stop sending new orders while leaving hedges in place. It must work when the system is already unhealthy, so it cannot depend on the components it is switching off, and it needs an out-of-band path that has been tested. And venues offer their own cancel-on- disconnect facilities, so knowing whether your orders die when your session drops is part of the design rather than an assumption.

One equity trade for an asset manager, with the actors and the clock.

Step             Who                          When, T+1 market
---------------  ---------------------------  ---------------------------
Execution        Venue matches, broker        T, in session
                 receives fills
Aggregation      Broker forms the block       T, seconds later
Allocation       Asset manager splits the     T, by evening cut-off
                 block across its funds
Enrichment       Broker attaches SSIs,        T, evening
                 fees, taxes, account data
Confirmation     Broker sends the terms       T, evening
Affirmation      Asset manager agrees, or     T, by ~21:00 local
                 it becomes a break
Clearing         CCP novates and nets         T evening / T+1 morning
Instruction      Custodians instruct the      T+1 morning
                 depository
Settlement       Depository moves stock       T+1, against payment
                 and cash
Reconciliation   Both sides agree positions   T+1 end of day
                 and cash

The column that matters is the third. Under T+2 most of the middle of this table happened overnight and a human cleared the exceptions the following morning; under T+1 those same steps have to complete on trade date evening, because the depository's deadline is now the next morning rather than the one after.

That is what settlement-cycle compression demanded of systems, and it is a better answer than "everything got faster". Batch jobs that ran at 2am became time-critical, which means they need monitoring, retries and an owner rather than a schedule. Affirmation moved from a next-day activity to a same-evening one, which pushed firms towards automated affirmation because a human queue could no longer absorb it. Cross-border flow lost its funding window, so the FX needed to pay for a US purchase must now be arranged on trade date, in a time zone where the Asian desk is closed. And securities lending recalls have to happen the same evening or the loaned stock is not back in time to deliver.

The structural consequence is that exception handling became the design centre rather than the edge. When there is slack, a break can wait for a person; when there is not, the system must either resolve it automatically or escalate it inside a couple of hours, which turns a queue into a workflow with SLAs. That is why post-trade modernisation is a live programme at most firms and why the 2027 European move keeps it funded.

An asset manager trades one block and then divides it across the underlying funds it was buying for, so one execution becomes many client trades. It is awkward because the split must be decided and communicated before a cut-off, because the price applied to each allocation is a policy choice — an average price across all fills, or specific fills to specific funds — and because rounding a block into several accounts leaves fractions that have to go somewhere by a documented rule. Get it wrong and one fund has been advantaged over another, which is a fairness issue with a regulator attached rather than merely a bug.

Confirmation is the broker stating the terms of the trade as it recorded them. Affirmation is the client agreeing that those terms match its own record. They are two directions of the same check and both must happen before the trade can settle cleanly, which is why they are separate steps with separate timestamps rather than one acknowledgement. What makes them interesting is the failure path: if the two records disagree on price, quantity, fees or settlement instructions, the trade does not affirm and lands in a break queue for a human to repair against a deadline. Automating affirmation is what a shortened settlement cycle effectively forced.

A central counterparty stands between the two sides of a cleared trade. Novation is the legal mechanism: the original bilateral contract is extinguished and replaced by two contracts, each facing the CCP, so neither original party carries the other's credit risk. In exchange the CCP demands initial margin against potential future exposure and variation margin as positions move, and it runs a default waterfall of the defaulter's margin, its own capital and a mutualised fund. The consequence to state is concentration: risk has been removed from participants and gathered in one institution, which is why CCPs are regulated as systemically important and why their margin models are scrutinised.

It reduces many obligations to few, which reduces both the number of settlements and the amount of cash and stock that must actually move. A hundred buys and ninety-five sells in the same instrument for the same settlement date become one net delivery, so the operational load and the funding requirement both fall by an order of magnitude. The consequence people miss is that netting destroys the one-to-one relationship between a trade and a settlement, so a failed net settlement cannot be attributed to a single trade, and reconciling a settlement back to the executions that produced it requires keeping the netting set explicitly rather than inferring it.

The seller cannot deliver the security on settlement date, so the exchange of stock for cash does not happen and the obligation remains outstanding. This is routine rather than exotic, which is why markets have machinery for it: cash penalties accruing daily in some jurisdictions, buy-in procedures where the failing party is forced out of the position at its own cost, and a securities lending market that exists partly so deliverable stock can be borrowed to cover. For a system builder, fails mean settlement status is a state machine with its own lifecycle rather than a boolean, and the fails queue is where a post-trade team spends most of its day.

Holds the securities, settles the trades and services the assets. Investors generally do not hold their own stock; a custodian keeps it in safekeeping, instructs the depository to deliver and receive, collects dividends and coupons, processes corporate actions, and reports the holdings. The chain can be several layers deep — a global custodian using sub-custodians in each local market — which is why cross-border settlement has more moving parts and more time zones than domestic. The engineering consequence is that your record of what you own is a claim that must be reconciled against the custodian's record, and any disagreement between the two is a break with money attached.

A golden source is the single system designated as authoritative for a particular kind of data — instruments, counterparties, accounts, calendars, prices — so that every other system consumes rather than maintains it. It matters because reference data is what all the interesting tables join against, so an error in it propagates into valuations, risk numbers, settlement instructions and reports simultaneously. The reason it generates defects is organisational rather than technical: it is nobody's exciting project, it arrives from multiple vendors that disagree, it changes without notice, and the systems consuming it each cached a copy years ago. Most production incidents in this domain are reference data incidents wearing another name.

Revaluing a position at current market prices rather than at what you paid, so the books show what it is worth now. In practice it is a data problem more than an arithmetic one, because "the market price" has to be defined: the last trade, the mid of the current quote, an official closing price, or a vendor's evaluated mark for something that has not traded. Each choice gives a different number and each is defensible for a different purpose, so the policy must be written down per instrument type and applied consistently. Where no observable price exists, the valuation comes from a model, and the inputs to that model become part of your reference data problem.

One position, two closes, and the decomposition the business actually asks for.

Day 1
  Open      no position
  Buy       10,000 shares @ 72.00              cost 720,000
  Close     price 72.80
  Value     10,000 x 72.80                          728,000
  Unrealised P&L                                     +8,000
  Realised P&L                                            0

Day 2
  Open      10,000 @ marked 72.80              value 728,000
  Sell       4,000 @ 73.50                  proceeds 294,000
  Close     price 72.10
  Position   6,000 shares
  Value      6,000 x 72.10                          432,600

  Realised on the sale, against the day 1 mark
             4,000 x (73.50 - 72.80)                 +2,800
  Unrealised on the remainder, against the mark
             6,000 x (72.10 - 72.80)                 -4,200
  Day 2 total P&L                                    -1,400

  Cumulative, against original cost
             realised 4,000 x (73.50 - 72.00)        +6,000
             unrealised 6,000 x (72.10 - 72.00)        +600
             total                                   +6,600

The subtlety is which baseline you measure against, and it changes the answer. Daily P&L measures every move from the previous close, so the day 2 realised figure is 2,800 against yesterday's mark, not 6,000 against the original cost. Both numbers are correct and they answer different questions: the daily figure feeds risk limits and the trader's day, the cumulative figure feeds the position's lifetime performance.

That is also why the two must reconcile. Cumulative P&L should equal the sum of the daily figures, and when it does not the cause is almost always a mark that was changed after the fact, a trade booked with the wrong trade date, or a corporate action applied on one side only. A daily-versus-cumulative reconciliation is therefore a genuinely useful control rather than a formality.

Two further practicalities. The cost basis convention — average cost against FIFO against specific lots — changes realised P&L on a partial sale, and it must match what the accounting and tax systems assume. And fees, commissions, taxes and funding costs are missing from the arithmetic above, which is exactly the gap between a trader's P&L and the firm's.

Splitting a period's profit and loss into the causes that produced it: market moves, new trades, carry and accruals, fees, and unexplained residual. It is demanded because an unexplained number is unusable — a desk cannot manage what it cannot decompose, and a risk function cannot validate a model that fails to predict its own P&L. The engineering interest is in the residual line, because a persistent one usually means a missing input, a stale mark or a position the system does not know about, so attribution doubles as a data quality control. Regulators lean on it too, since a model whose attributed P&L drifts from actual is evidence the model is wrong.

Value at risk is a single number describing how much a portfolio might lose over a given horizon at a given confidence — a one-day 99% VaR of two million means that on 99 days in 100 you would expect to lose less than that. It is computed historically, parametrically or by Monte Carlo, and all three depend on a covariance or scenario set built from the past. What it does not tell you is how bad the other one per cent is, which is the whole reason expected shortfall exists as a complement, and it says nothing about a regime it never observed. Treat it as a communication device with known blind spots.

Sensitivities of an option's value to each input, and what each one implies for a system.

Greek   Sensitivity to        Sign, long call    What it forces on a system
------  --------------------  -----------------  ---------------------------------
Delta   underlying price      positive           re-hedge as price moves; drives
                                                 the hedge order flow
Gamma   change in delta       positive           delta moves, so hedges must be
                                                 revised, not set once
Vega    implied volatility    positive           you need a volatility surface as
                                                 an input, not a single number
Theta   passage of time       negative           value changes with no market
                                                 move, so a daily roll is real
Rho     interest rates        positive           a discount curve is an input

The one to lead with is gamma, because it is what makes options operationally different from cash instruments. Delta tells you how many shares to hold to be hedged now; gamma tells you that the answer changes as the price moves, so hedging is a continuous process generating order flow rather than a one-off trade. A system supporting an options desk therefore has a re-hedging loop, and its frequency is a cost-versus-risk decision.

Vega is the one that reveals whether a candidate has seen a real pricing system. It implies that implied volatility is an input, and implied volatility is not one number but a surface across strikes and expiries, which must be built, stored, interpolated and version-controlled. That surface is usually the largest and most troublesome piece of market data an options system owns.

Theta is worth naming because it breaks an assumption engineers carry in from elsewhere: the value of the position changes overnight even though nothing traded, so a reconciliation that expects an unchanged mark on a quiet day will report a false break every single day.

Initial margin is collateral held up front against potential future exposure — what the position could lose over the time it would take to close it out if you defaulted — and it is calculated by a model, so it changes as volatility changes. Variation margin is the daily, sometimes intraday, movement of collateral to reflect what the position has actually gained or lost, so it settles the mark-to-market. The distinction matters operationally because they have different rhythms: initial margin is recalculated periodically and can jump when markets turn, while variation margin is a daily cash flow that must be funded, and a margin call you cannot meet is a default regardless of solvency.

Realised P&L is locked in by a closing trade, unrealised is the current mark-to-market on a position you still hold. The distinction is economic rather than cosmetic because they behave differently: unrealised P&L can reverse, and it depends on your choice of mark, so it is only as trustworthy as the price source behind it. The place it bites in engineering is the boundary between them. A partial close realises some of the gain and leaves the rest unrealised, and how much is realised depends on the cost basis convention, so the same trades under average cost and under FIFO produce different realised figures and identical total P&L.

A high-volume, sequenced stream of updates from a venue, usually multicast on the local network and usually incremental rather than full-state. Each message adjusts the book — a new order at a level, a cancellation, a trade — so your view of the market is correct only if you have applied every message in order. That single property is what makes market data engineering different from ordinary stream consumption: there is no forgiving path, because a missed message leaves you with a book that is plausibly wrong rather than obviously broken. Feeds therefore ship with sequence numbers, a snapshot channel, a retransmission service and usually two redundant copies.

The same moment, the same instrument, at two depths.

Level 1, top of book
  BID   10.01   500        ASK   10.02   500

Level 2, aggregated depth by price level
  BID                          ASK
  10.01   500   3 orders       10.02   500   2 orders
  10.00   900   5 orders       10.03   400   1 order
   9.99  2,100  9 orders       10.04  1,800  6 orders
   9.98  1,400  6 orders       10.05  3,200  11 orders

Cost of buying 1,500 shares immediately
  From level 1 alone you would guess   1,500 x 10.02 = 15,030
  From level 2 you can compute
      500 @ 10.02 =  5,010
      400 @ 10.03 =  4,012
      600 @ 10.04 =  6,024
                     ------
                     15,046   and the new best ask is 10.04

Level 1 is enough to know the price and nothing about the cost of size, which is why a system that subscribes only to top of book cannot estimate slippage, cannot size an order sensibly and cannot detect that the book has thinned. Level 2 makes both computable, at roughly one to two orders of magnitude more messages.

The order count column is the detail worth noticing. Aggregated level 2 tells you how much is resting at each price but not who is where in the queue, so you cannot compute your own queue position from it — that requires level 3, the order-by-order feed. Any fill probability model built on aggregated data is guessing at the thing that actually determines whether you fill.

The consumption difference is what an interviewer is checking. Level 1 arrives at a rate any ordinary service can handle and can reasonably be conflated. Level 2 in an active name is a continuous stream of small mutations, and the correctness requirement is total — apply every message in sequence or your depth is fiction — which is why the book builder is the piece of a market data system that gets written most carefully and tested against captured data rather than synthetic input.

The order-by-order view: each individual order's arrival, modification and removal, rather than the aggregate at each price. It is what lets you reconstruct the queue at a price level and therefore reason about your own priority, which matters to anyone whose economics depend on being filled rather than on the price being right — market makers and latency-sensitive strategies. The cost is volume and complexity: message rates are far higher than aggregated depth, and you now maintain per-order state with its own lifecycle. Most systems do not need it, and recognising that a fill probability question requires it is the interesting part.

Sequence numbers make gaps detectable, and the recovery choice is the design decision.

sequenceDiagram
    participant F as Feed multicast
    participant H as Feed handler
    participant R as Retransmission service
    participant S as Snapshot channel
    F->>H: seq 1001, 1002, 1003
    F->>H: seq 1007 - gap of three detected
    H->>R: request 1004 to 1006
    R-->>H: 1004, 1005, 1006 replayed
    H->>S: if gap too large, rebuild instead
    S-->>H: full book snapshot plus resume sequence

The handler must buffer live messages while recovering, because the feed does not pause. Applying 1007 before 1004 corrupts the book silently, so the arriving stream goes into a queue until the gap is filled and then drains in order — and that buffer is a bounded resource, which is why a long recovery becomes a second failure.

The choice between retransmission and snapshot is about size and speed. A gap of three messages is cheaper to replay; a gap of fifty thousand, which is what a brief overload produces at the open, is cheaper to abandon in favour of a snapshot and a resume point. So a mature feed handler has a threshold, and picking it is an empirical exercise against captured data from the busiest minutes of the day.

Two details separate people who have run this. Falling behind is the real enemy, because a slow consumer converts a small gap into a large one and then into a recovery that also cannot keep up — the failure compounds rather than being absorbed. And most venues publish two identical feeds on different paths, so the first defence is line arbitration: take whichever copy delivers each sequence number first, and a loss on one line never becomes a gap at all.

Dropping intermediate updates and delivering only the latest state for an instrument when a consumer cannot keep up. It is acceptable when the consumer wants current state rather than every event — a trader's screen, a valuation service, a risk dashboard — because seeing the price go 10.01, 10.02, 10.03 adds nothing over seeing 10.03. It is unacceptable anywhere the sequence carries meaning: book building needs every increment, trade printing needs every print, and surveillance needs the sequence itself. So conflation belongs at the distribution edge, per subscriber, and never inside the book builder that downstream consumers depend on.

Size the storage before choosing the store, because the answer changes which technology is even a candidate.

Assume 3,000 instruments, one venue, aggregated depth

  quote updates per instrument per day, average      12,000
  trades per instrument per day, average               1,200
  events per day       3,000 x 13,200            =  39,600,000
  bytes per event, naive row with timestamps          ~100 B
  raw per day          39,600,000 x 100           =   3.96 GB
  per year, 252 trading days                      =    998 GB
  three venues                                    =    ~3 TB/year
  seven-year retention                            =   ~21 TB

Same data columnar, delta-encoded timestamps, dictionary
symbols, prices as scaled integers
  effective bytes per event                            ~8 B
  per year, three venues                          =   ~240 GB
  seven-year retention                            =   ~1.7 TB

The compression ratio is the whole answer, and it is not incidental. Tick data is almost perfectly compressible because consecutive timestamps differ by microseconds, symbols repeat endlessly and prices move in small increments from the previous value, so columnar storage with delta encoding routinely achieves an order of magnitude or better. Storing ticks as rows in a general-purpose relational table is choosing the twenty-one terabyte column for no benefit.

The access pattern reinforces it. Queries are almost always "this instrument, this time range, these fields" — a contiguous slice of a few columns — which is exactly what a column store serves from one sequential read while a row store reads every field of every row to discard most of them.

Two design consequences to state unprompted. Peak matters more than average: the first minute after the open can carry several per cent of the day's messages, so the ingest path must be sized for the burst while the storage estimate is sized for the total. And retention is a business decision to extract rather than assume, because the regulatory requirement to reconstruct a trade and the desk's wish to backtest ten years are different requirements with very different costs, often solved by keeping full ticks recent and aggregated bars for history.

In a columnar, time-partitioned store — a purpose-built time-series database or column files partitioned by date and instrument — because the queries are range scans over a few columns and the data compresses enormously when stored by column. A row per tick in a general-purpose relational table pays index maintenance on every insert at a rate the table was never designed for, stores each field separately at full width, and then reads all fields to answer a query that wanted two. The other reason is lifecycle: partitioning by date makes dropping or archiving a period an instant metadata operation rather than a month-long delete.

An obligation on a broker to take all sufficient steps to obtain the best possible result for a client, judged across price, cost, speed, likelihood of execution and settlement, size and nature — not price alone. The systems consequence is evidential: you must be able to show afterwards why each order went where it did, which means capturing the market state you observed, the routing decision and its inputs, and the outcome, then monitoring execution quality against benchmarks over time. In other words a policy document is not compliance; the data to demonstrate adherence is, and producing it is a permanent data engineering commitment rather than a project.

Traceability to UTC and a maximum divergence, tightened according to activity — firms engaged in high-frequency algorithmic trading face the strictest requirement, with reportable event timestamps at microsecond granularity, while less latency-sensitive activity is allowed more. The engineering consequence is that ordinary network time service is generally insufficient at the strict end, so firms deploy precision time protocol with hardware timestamping, and they must document and monitor the divergence rather than assume it. The reason behind the rule is reconstruction: if two venues' event streams cannot be ordered against each other, no regulator can determine what happened, and neither can you when investigating your own incident.

The obligation to report the details of executed transactions to a regulator, promptly and in a prescribed format with dozens of fields covering instrument, price, quantity, timing, venue, capacity and the identities of the parties and the decision makers. It is never finished because the field definitions change, the instrument scope changes, and much of the content comes from reference data maintained elsewhere, so a reporting system is permanently coupled to every upstream that owns a piece of the record. The characteristic failure is completeness rather than availability: nobody notices a missing report until a reconciliation between what you executed and what you reported is run, which is why that reconciliation is itself a required control.

Because FIX is a framework rather than a fixed contract. Counterparties differ in version, in which of the optional fields they require, in the custom tags above 5000 they invented for their own workflow, in the order types and time-in-force values they accept, and in the sequence and content of the execution reports they send back. Two systems that both implement the specification correctly still need a certification exercise per counterparty, driven by that counterparty's rules of engagement document, with a test script covering rejects and cancel races rather than only the happy path. Budgeting a fortnight per venue rather than an afternoon is the answer that shows experience.

They collapse them, and describe a model where an order hits the exchange and the buyer then owns the shares. Clearing establishes what each party owes, novates the trade to a central counterparty where one is involved, and collateralises the exposure in the meantime; settlement is the later exchange of securities against cash through a depository, on settlement date. So a matched trade is a promise and nothing more, ownership changes on settlement date, and the gap between the two is where fails, margin, securities lending and most of the domain's machinery live. Placing a given system at execution, clearing or settlement is the check.

A strong answer starts with the numbers. A busy instrument's book mutates tens of thousands of times a second and every mutation must be visible before the next decision, so the budget per operation is sub-microsecond, while a database round trip is hundreds of microseconds and its durability guarantee costs a synchronous log flush per commit. The workload is also wrong for the tool: one writer, no ad hoc queries, no joins, and a working set small enough for memory, so every relational feature being paid for is unused. It then says what replaces it — the book as sorted price levels of FIFO queues in memory, a single writer for determinism, durability from an append-only sequenced input log that can be replayed to reconstruct state — and notes that replay, standby failover and audit come free with that choice. It closes by naming where a database still belongs: reference data, trades, positions, allocations and everything post-trade, where volumes are ordinary and transactional integrity is exactly what you want. A weak answer says relational databases are slow, which is a slogan rather than a distinction between the hot path and the rest of the system.