Architecture & Systems
Pricing Library Architecture (Instrument–Market–Model–Pricer)
Separate contract, data, assumptions, and numerical method so the library can grow without breaking.
Mental model
The instrument defines the promise, the market defines the state, the model defines the assumptions, and the pricer joins them.
Instruments encode contract terms and payoff logic but never fetch market data.
Market snapshots are immutable, versioned containers for curves, vols, and fixings.
Explore the mechanism
Which responsibility belongs to the instrument, market state, model, and numerical pricer?
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.
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).
What to notice
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.
Where it appears
- adding products without duplicating market logic
- testing valuation components independently
- supporting multiple models for one instrument
Where the intuition breaks
What this view leaves out
- Separation adds interfaces and configuration; poor boundaries can move complexity rather than reduce it.
Where this concept sits
Follow the strongest prerequisites, applications, extensions, and contrasts.
Connections for Pricing Library Architecture (Instrument–Market–Model–Pricer)
A product–pricer registry operationalises the separation between instrument definitions and pricing implementations.
SupportsMarket and Model VersioningA clean instrument–market–model–pricer architecture makes model and market versions explicit inputs rather than hidden global state.
UsesLibrary Release VersioningA production pricing library uses explicit releases so each valuation can be tied to a known implementation state.
SupportsBlack–Scholes Option PricingA common pricing interface can expose a Black–Scholes analytical pricer without making the architecture itself the mathematical implementation.
SupportsMonte Carlo PricingA common instrument–market–model–pricer interface can host Monte Carlo engines without making the architecture itself perform the simulation.
A product–pricer registry operationalises the separation between instrument definitions and pricing implementations.
Explore concept →