QuantLib as a service: hosted API vs self-hosting (and where ORE fits)

01The three routes

1 · Self-host QuantLib. The reference open-source library for quantitative finance: instruments, term structures, models, pricing engines. Free, and you control everything — which also means you build (or pip-install) it, assemble the day counts, calendars, schedules and curves yourself, track version upgrades, and write the serving layer if anything other than one script needs the numbers.

2 · Self-host ORE. The Open Source Risk Engine wraps QuantLib in a portfolio-level application: trade and market data input, NPV and cash-flow reports, sensitivities, XVA, scenario generation, market risk. Also free, and considerably more complete than any hosted calculator — at the price of a heavyweight deployment, XML configuration and a real learning curve.

3 · Call a hosted API. Quant-Box exposes five QuantLib-backed endpoints over HTTPS — option pricing with greeks, implied volatility, bond pricing with duration/convexity/BPV, curve bootstrapping, VaR/ES — with the conventions written into every response. Nobody on your side builds or upgrades anything. In exchange you accept a deliberately narrow scope and a dependency on a third party.

02An honest comparison

None of the three is wrong. QuantLib self-hosted is the most powerful and the most work; ORE is the most complete risk platform and the heaviest deployment; a hosted API is the fastest to a correct number and the least flexible.

03Time to first number

The concrete difference the hosted route buys. A 5% annual-coupon bond issued 2024-07-01, maturing 2029-07-01, settling 2026-10-15, at a flat 4% yield:

import requests

r = requests.post("https://quantbox.dev/v1/bonds/price",
    headers={"X-API-Key": KEY},
    json={"coupon_rate": 0.05, "issue_date": "2024-07-01",
          "maturity_date": "2029-07-01", "settlement_date": "2026-10-15",
          "yield_rate": 0.04})
print(r.json()["clean_price"])   # 102.4892

{
  "clean_price": 102.4892,
  "dirty_price": 103.9413,
  "accrued": 1.4521,
  "ytm": 0.04,
  "modified_duration": 2.4748,
  "convexity": 8.7012,
  "bpv": -0.0257,
  "conventions": {
    "prices": "per 100 of face value (market quote convention)",
    "settlement": "as provided (settlementDays=0, no implicit T+2)",
    "ytm": "compounded annual, act/act",
    "calendar": "TARGET, unadjusted schedule"
  }
}

Self-hosted, the same number means installing QuantLib, then constructing the schedule, day counter, calendar and yield term structure by hand — a fine afternoon if bond pricing is your job, a detour if it is not. The full walkthroughs: price a bond from a yield or a curve and bootstrap a yield curve over HTTP.

04Verdict by use case

05When NOT to use Quant-Box

Being explicit about the boundary is cheaper than a disappointed integration:

XVA. No CVA, DVA, FVA or collateral simulation. That is ORE territory.

Complex exotics. Options are vanilla European (analytic) or American (binomial). No barriers, baskets, Asians or other path-dependent payoffs.

Volatility surface calibration. Implied vol is a single-price inversion. There is no SABR, SVI or Heston calibration.

Market data. Quant-Box supplies no quotes, curves or fixings — every number is computed from inputs you send. If you expect data with your analytics, you need a data vendor first.

Hard data-residency rules. Nothing is stored beyond the request and inputs are anonymous numbers, but the call itself crosses your boundary. If that is disqualifying, self-host — that is the honest answer.

And the structural one: a hosted API is a dependency. If quantbox.dev is unreachable, so are your numbers. Uptime matters to us for obvious reasons, but a bank's core risk system should not hang off anyone's hosted calculator — including this one.