AAD vs bump and revalue
Both give the sensitivities of a price or risk number to its inputs. Bump and revalue prices again once per risk factor. AAD (adjoint algorithmic differentiation) gets all of them from one extra pass through the code. The more risk factors, the wider the gap.
The two methods in one paragraph each
Bump and revalue, also called finite differences or bumping: shift one input by a small amount, revalue, and divide the change in value by the shift. Repeat for every input. Central differences shift each input both ways for a better estimate, at twice the cost. It needs no change to the pricing code, which is why it is everywhere.
AAD records the operations of one valuation and then runs through that record backwards with the chain rule, collecting the sensitivity of the result to every input in a single pass. It needs the code to run on an AAD library, such as XAD. What is AAD explains how it works, with a worked example.
Cost: grows with risk factors, or does not
| Bump and revalue | AAD | |
|---|---|---|
| Cost of all first-order sensitivities | One valuation per risk factor, plus the base run; twice that for central differences | As little as 2 times the cost of one valuation with XAD's tape, whatever the number of risk factors |
| As risk factors grow | Grows in step with them | Stays flat |
| Change to the pricing code | None | Runs on an AAD library; checked against bumping |
| Memory | One valuation at a time | The record of one valuation, kept in bounds by checkpointing |
The ratio follows from the first row: with N risk factors, bumping costs about N valuations and AAD from about 2, so AAD is up to about N/2 times faster. Where code generation also makes the valuation itself faster, the gain goes beyond that ceiling: on a Monte Carlo CVA with 90 inputs, QuantLib with AAD computes all sensitivities up to 270× faster than bumping (measured November 2026; method and every case). With code generation, the whole run, every sensitivity included, is up to 3 times faster than one plain valuation of the original code.
Accuracy: an estimate, or the exact derivative
- Bumping estimates. The answer depends on the size of the shift. Too large and the curvature of the price leaks in; too small and rounding and Monte Carlo noise swamp the change. Each risk factor may need its own shift size, and Monte Carlo prices must reuse the same random numbers or the difference is mostly noise.
- AAD is exact for the code as written, to machine precision, with no shift size to choose. It differentiates what the code does, so on a discontinuous payoff (a digital, a barrier) pathwise AAD misses the jump and usually gives zero; such payoffs need smoothing or a dedicated treatment first, as they do for bumping. The smoothed mathematics tutorial shows how.
In practice the two are run side by side when AAD goes in: every sensitivity is checked against bumping, risk factor by risk factor, before AAD replaces it. That check is part of every AAD enablement project and what model validation asks to see.
When bumping still makes sense
- Few risk factors: with three or four, bumping costs about as much as AAD and needs no change to the code.
- Code you cannot change or recompile, such as a vendor library you only call.
- Results defined as full revaluations under a shift, such as FRTB curvature; there AAD still speeds up the delta and vega that come with them.
- As the reference that AAD sensitivities are checked against.
Moving from one to the other
Most banks keep bumping where it is cheap and move the heavy runs to AAD first: XVA and its sensitivities, SA-CVA and FRTB capital, initial margin and MVA, calibration. The case studies show what that gave on banks' own code.
- XAD, the AAD library for C++ and Python, and its AAD tutorial.
- AAD training, for teams that want to build it themselves.
- AAD enablement, for AAD built into your own code.
- QuantLib with AAD: all sensitivities of a QuantLib pricing in one adjoint pass.
- A free speed-up estimate of what AAD would give on one of your calculations.