Open Risk Engine (ORE) is built on QuantLib, one of the largest open-source C++ libraries in finance. It has thousands of classes, deep inheritance hierarchies, and decades of accumulated complexity. Nobody fully understands all of it.
The question: can you accelerate ORE without understanding its internals?
The black-box approach
Instead of refactoring QuantLib’s C++ code, we record it:
- Hook inputs: Replace the market data entry points (yield curves, FX spots) with active types.
- Hook outputs: Capture the NPV calculation result.
- Record: Run ORE’s existing pricing path once. Every operation (curve interpolation, discount factor calculation, cashflow projection) is captured on the tape.
- Compile: JIT-compile the tape to a native kernel.
- Replay: Feed new market data, get prices and Greeks in microseconds.
Zero modifications to QuantLib’s internal C++ code. Zero understanding of the class hierarchy required.
Results: FX linear products
| Metric | ORE (original) | Compiled Kernel |
|---|---|---|
| 1M FX trades — NPV | 98 seconds | 0.4 seconds (245×) |
| Full delta risk | Hours (bump-and-revalue) | <1 second (adjoint) |
| Recording time | — | 350 seconds (one-time, pre-market) |
| Active-to-passive conversions | — | 0 (clean recording) |
The 350-second recording is a one-time cost at start of day. After that, every market data update triggers a kernel replay at sub-second latency.
Control flow handling
ORE/QuantLib uses dynamic dispatch, virtual functions, and runtime branching throughout. The recording captures the specific execution path taken for the given trade population. This means:
- Adding a new trade type that exercises a different code path requires re-recording.
- Changing market data does NOT require re-recording (market data are kernel inputs).
- The kernel is specific to the trade population’s structure, not its parameters.
Production workflow
- Pre-market (6:00 AM): Load trade population, record all kernels (~350s). Cache to disk.
- Market open: Load cached kernels. Set market data inputs. Replay for NPV + Greeks.
- Intraday: On each market data tick, replay the kernel. Sub-second full portfolio risk.
- End of day: Archive kernels for audit trail.
What this means
ORE has 500,000+ lines of C++ code. A traditional optimization project would take years and require deep QuantLib expertise. The black-box approach took weeks and required understanding only the input/output boundaries.
The same pattern applies to any pricing library: in-house C++ code, vendor libraries, even legacy Fortran. If it runs on a CPU with double arithmetic, it can be recorded.
Implemented using AADC, a commercial adjoint AD compiler (matlogica.com).
Frequently Asked Questions
How much faster is ORE with AADC?
MatLogica AADC accelerates ORE/QuantLib by 100x+ for FX linear products. Baseline ORE takes 98 seconds to price 1 million trades. After one-time AADC recording (350 seconds, done pre-market), NPV recalculation takes just 0.4 seconds (245x faster), and NPV plus all delta risks takes under 1 second (100x+ faster with complete sensitivities).
Do I need to understand ORE’s C++ hierarchy to use AADC?
No. The black box approach requires only identifying where market data enters (CSVLoader::loadFile) and where valuations exit (ReportWriter::writeNpv). You hook AADC at these points using markAsInput() and markAsOutput() without needing to understand ORE’s internal complexity.
Is AADC an approximation method for ORE?
No, AADC delivers machine precision accuracy, not approximations. It eliminates computational overhead while preserving the mathematical integrity of ORE/QuantLib models.
Can AADC work with proprietary quant libraries besides ORE?
Yes, the black box technique works with any C++, C#, or Python quantitative library, not just ORE/QuantLib. You identify input/output points in your proprietary code and hook AADC the same way.