Quant with Vahab
Quant Systems Lab · Control Systems for Quantitative Finance

Pricing Library Architecture (Instrument–Market–Model–Pricer)

Separate contract, data, assumptions, and numerical method so the library can grow without breaking.

Explanation

Instruments encode contract terms and payoff logic but never fetch market data.

Market snapshots are immutable, versioned containers for curves, vols, and fixings.

Models encapsulate dynamics and calibrated parameters tied to a specific market snapshot.

Pricers are pure functions that map (trade, market, model, settings) to prices and diagnostics.

Risk and portfolio layers sit on top as consumers: they orchestrate bumps, scenarios, and aggregation, not pricing logic.


architectureinstrumentmarketmodelpricer
Interactive visualisation

This schematic shows a pricing library split into Instrument → Market → Model → Pricer layers. Use the controls to see how many artefacts live in each layer and how the number of dependencies explodes if you hard-wire everything together instead of routing logic through a clean stack.

Pricing contexts: 20
InstrumentsContract & payoff5 objsMarket snapshotsCurves & vols2 objsModelsDynamics & params4 objsPricersNumerical method5 implslayer boundaryintended dependencyhard-wired shortcut
Numbers
Instruments: 5 · snapshots: 2 · models: 4 · pricers: 5
Distinct pricing contexts (trade × market × model × pricer): 20
Clean-layer dependency edges ≈ 14
Tightly coupled edges ≈ 65 (≈ 5× more)
Interpretation

A clean architecture keeps contracts, data,models, and pricers in separate layers. Adding more trades or market snapshots multiplies the number of pricing contexts, but the number of dependencies grows only linearly.

In the tangled version, instruments reach straight into markets and models and pricers depend on everything. The dependency count explodes, making the library brittle: a small change in one place can break many routes. The mental model: combinatorics is inevitable in pricing, but you can choose whether it lives in data and artefacts (composable) or in code-level dependencies (fragile).