Module 7 · Advanced
Inside a margin engine
Strip away the methodology and a margin engine is a pipeline — seven stages between a trade hitting the book and a margin call going out. Two properties matter more than raw speed: every number must be reproducible(a client disputing yesterday's call gets an exact answer, not a shrug), and the parts that change often — grids, add-ons, stress definitions — must be configuration, not code, because risk policy moves faster than release cycles.
🎛 Pipeline explorer
Click a stage — then flip the mode and watch where the time goes
Full-book run (per client, illustrative)
199.0s
Fine for a nightly cycle — useless as an API response.
A client-facing what-if margin API is the same pipeline with stages 1–3 answered from cache and stage 4 shrunk to the marginal trade. That inversion — from batch job to millisecond service — is the hard engineering in prime brokerage margin, and it's why 24/7 markets (which dissolve the batch window entirely) force continuous incremental recompute. Educational tool — not investment advice.
The hard problem: pre-trade what-if margin
A client asks: “what happens to my requirement if I add this trade?”The answer must come back in milliseconds — through an API, to an external customer — not in tonight's batch. That inverts the whole design: portfolio state, market data snapshot and scenario grid live in cache, and the engine reprices only the marginal trade against the cached grid, then re-aggregates. Flip the mode in the explorer above to see where the time goes in each world. When a venue trades 24/7, this stops being a nice-to-have: with no batch window at all, incremental recompute is the only architecture left.
The reproducibility test
“A client disputes yesterday's margin call — how does your system let you answer?” is the single best interview question about margin engines, because it forces the whole architecture out: versioned and immutable market data snapshots, deterministic runs keyed on (positions, snapshot version, config version), and stored intermediate results so you can show which scenario drove the number. If any stage pulls live data at run time, reproducibility is already gone.
Next door: the financing side
Prime-brokerage margin doesn't stand alone — it sits beside securities lending and repo, and the margin engine ultimately protects the financing spread, which is the actual revenue line. The adjacent vocabulary: repo haircuts (the same MPOR logic, protecting the cash lender against collateral decline — see the repo module), rehypothecation limits (they cap how far client collateral can be re-lent, and so constrain financing capacity), and tri-party custody(why clients demand it after the 2022 failures — collateral that lives at a neutral agent survives your broker's bankruptcy).
Things to try
- • In batch mode, note that repricing dwarfs everything — that's why the cache key is (instrument, market-data-version, scenario) and nothing else.
- • In what-if mode, stages 2 and 3 read “cached” — the snapshot and grid are reused, which is also exactly what makes the answer reproducible.
- • Ask of each stage: if this stage re-ran twice on the same inputs, could the answer differ? Any “yes” is a reproducibility bug.