Quantitative risk infrastructure for a portfolio operation: Monte Carlo simulation at a hundred thousand price paths, under Geometric Brownian Motion and Heston stochastic volatility, GPU-accelerated with CUDA — feeding value-at-risk and scenario answers fast enough to be used before decisions rather than after them.
Who this story is for
Any desk or portfolio operation whose risk process currently lives in a workbook named something like FINAL_VaR_v7, and where the answer to “what if we double this position” arrives after the decision has been made.
The problem with slow risk
Risk numbers that take overnight to compute answer yesterday’s question. The desk asks what happens if a position doubles, or if volatility spikes, and the honest response is that the model runs tonight.
So one of two things happens. Either the question goes unanswered and the decision is made on instinct, or a static value-at-risk figure computed when the portfolio looked different gets quoted with more confidence than it deserves. Both are worse than they appear, because the second one carries the authority of a number.
Speed is not a luxury in risk. It is the difference between a control and a post-mortem.
What I built
The simulation engine. A hundred thousand paths per run, using Geometric Brownian Motion for the base case and the Heston stochastic-volatility model where volatility’s own volatility matters — Indian mid-caps, anything that gaps, any instrument where the constant-volatility assumption quietly lies.
GPU acceleration via CUDA kernels, written with CuPy. This is the change that made the rest useful: computations that had been coffee-break exercises became sub-second answers. The engineering is not exotic — path generation is embarrassingly parallel, which is precisely the workload a GPU exists for — but the effect on how the desk works is qualitative rather than incremental. Questions get asked that previously were not worth asking.
Parametric value-at-risk at 95 and 99 per cent for the daily rhythm, with full simulation reserved for the questions where a point estimate is inadequate and the shape of the distribution is the actual answer.
Calibration discipline. Parameters refreshed from live data, staleness alarmed, and every result stamped with the assumptions that produced it. A risk number without its assumptions attached is astrology in a suit — it invites confident use by someone who does not know what was assumed on their behalf.
Wired into real positions. The engine runs over the portfolio system’s event-sourced truth rather than an export, so simulations reflect what is actually held right now. Risk computed on stale positions is a category of error that produces very convincing wrong answers.
What it changed
The risk process moved from a nightly report that was read to an instrument that was used. That is the whole outcome, and it is easy to understate: the same maths, made fast enough to sit inside a decision rather than beside it.
[METRIC — sign-off: runtime before/after, and portfolio scale, if shareable]
The secondary effect was cultural. When answers take a minute, people explore — three scenarios instead of one, the tail as well as the central case. That exploration is where risk work actually earns its keep, and it simply does not happen when each question costs a night.
The honest scope
This is infrastructure rather than advice. It does not tell anyone what to trade, it does not generate signals, and nothing it produces is a recommendation. Models are approximations of a world that does not read them: Heston is better than Black-Scholes at describing volatility clustering and it remains a model, and a hundred thousand paths sample a distribution rather than revealing one.
What good risk infrastructure provides is a defensible, current, assumption-stamped estimate available fast enough to inform a decision. Anyone promising more than that is selling certainty that the mathematics does not contain.
What it means for you
This depth of quantitative engineering is unusual outside institutional desks, which is precisely why smaller operations run on spreadsheets. The components now form the risk layer of the Trade Desk product, and the accounting foundation beneath them is the Portfolio Manager.
Why the GPU work was worth doing
It is fair to ask whether this is over-engineering for a portfolio operation, and the answer is that the acceleration is what converted the model from a report into a tool.
At overnight speed, simulation is a compliance artefact — computed because a mandate requires it, filed, and rarely consulted. At sub-second speed it becomes part of the conversation about a position, which is the only context where a risk number can actually change an outcome.
The implementation itself is modest: path generation parallelises almost perfectly, CuPy exposes CUDA without writing kernels by hand, and the calibration layer is ordinary Python. The unusual part is not the technique — it is that somebody applied it at this scale of operation, where the assumption is normally that this kind of engineering belongs only to institutions.
Related reading
/work/portfolio-system — the position truth underneath · /products/trade-desk — the productised desk layer · /industries/wealth — the trade context · /services/fintech — the practice
If your VaR lives in a spreadsheet
That is not unusual and it is worth changing, because the version that runs in seconds gets used. /contact — not investment advice, infrastructure only.