The full requirements map
The complete functional surface of the exchange we're building — the checklist Part 1 will implement.
Lesson 0.1 gave the venue four jobs. Each branch below refines one of them, plus the trust machinery that makes the result admissible and auditable.
The obvious shortcut is to design the matching engine first and label accounts, market data, custody, surveillance, and reference data as interchangeable supporting services. Yet before choosing topology, every requirement has an owner, an authoritative state source, and an explicit consequence when that capability is unavailable.
Most "build an exchange" write-ups cover only the matching engine. That's perhaps a fifth of the system. Here is the whole map — skim it now, and return to it whenever you want to know where a lesson fits:
mindmap
root((Exchange))
Order intake
Accounts and onboarding
Sessions and connectivity
Order entry, cancel, modify
Pre-trade risk checks
Matching
Central limit order book
Price-time priority
Order types and time in force
Auctions open and close
Halts and circuit breakers
Market data
Top of book L1
Depth of book L2
Every event L3
Delayed and historical
Post-trade
Trade capture
Clearing and netting
Settlement T+1
Custody ledger
Trust
Surveillance
Audit trail
Reference data
Regulatory reporting
Two observations to carry forward. First, the branches have wildly different consistency needs: matching must be perfectly ordered and deterministic; surveillance can lag by minutes. Second, they have wildly different availability needs — a theme Part 3 turns into a design method: spend your reliability budget where an outage stops trading, not where it delays a report.
A venue can match every order correctly and still fail as an exchange if no component captures obligations for clearing. The fill report would exist, but cash and shares would never change legal owner. Functional completeness is a correctness property, not a feature count.
The matching engine is the heart, but only ~20% of the system. Different branches need different consistency and availability — exploit that.