Quant Summit London 2026

The first talk was focused on the state of SVI (Stochastic Volatility Inspired) support in ORE. To recap why this would be useful, Aurell tell us that:

The SVI implied volatility model is a parametric model for stochastic implied volatility. The SVI is interesting because of the possibility to state explicit conditions on its parameters so that the model does not generate prices where static arbitrage opportunities can occur. Calibration of the SVI model to real market data requires non-linear optimization algorithms and can be quite time consuming. In recent years, methods to calibrate the SVI model that use its inherent structure to reduce the dimensions of the optimization problem have been invented in order to speed up the calibration.

Figure 2: The SVI model family.

If I understood correctly, SVI will appear within the curve config as a form of interpolation, available for strike and time interpolation. The two types of arbitrage that were mentioned were calendar arb and fly arb, but I wonder from browsing Aurell if there are other types of static arbitrage that the SVI family can help with.

The guru Peter Caspers spoke about Local Vol support in ORE. As a brief overview on the topic:

Local volatility (LV) models compute volatility as a deterministic function of the current asset price and time, \(\sigma(S_t, t)\), allowing for a perfect fit to market prices but poor dynamic hedging. Stochastic volatility (SV) models, such as Heston or SABR, treat volatility itself as a random process, providing superior dynamic hedging and capturing realistic smile evolution.

For a treatment more amenable to the lay, see Kumar Jha's Local vs Stochastic Volatility: Easiest Explanation.

Figure 3: Peter Caspers discussing Local Vol support.

I must say, it is still unclear to me how Local Vol and Stochastic Vol should interact in the context of intraday risk management, but I suspect a lot of these concepts will only become clear once I advance ORE Studio sufficiently to be able to play with them interactively. And to further complicate matters — if I understood Caspers correctly — you also need to take into account stochastic rates, as these impact even the short end of the curve these days, meaning you also need to correct for those. At any rate, it is great to see that ORE is catering for all of these real world features of vol surface management.

Sarp Kaya Acar made a presentation about modeling in commodities — an asset class to which I know next to nothing. On the plus side, Acar's presentation provided sufficient context to allow a layperson a modicum of understanding on the motivation of these changes, as the figure demonstrates.

Figure 4: Limitations of single factor models.

The gist of it is that existing commodity models in ORE support only a single factor and no seasonality. In the real world, this model is too simplistic and the eventual target is to generalise support to \(n\) factors, much like models in R provide and for very much the same reasons:

‘NFCP’ (N-Factor Commodity Pricing) provides a framework for the modeling, parameter estimation, probabilistic forecasting [of] European and American options on futures contracts valuation and simulation of commodity prices through state space and Monte Carlo methods, risk-neutral valuation and Kalman filtering. Commodity pricing models are systems of stochastic differential equations that are utilized for the valuation and hedging of commodity contingent claims (i.e. derivative products on the commodity) and other commodity related investments. Parameters of commodity pricing models are estimated through maximum likelihood estimation (MLE), using available term structure futures data of a commodity. Commodity pricing models that capture market dynamics are of great importance to commodity market participants in order to exercise sound investment and risk-management strategies. The N-factor commodity pricing model framework was first presented in the work of Cortazar and Naranjo (2006) titled “An N-Factor Gaussian Model of Oil Futures Prices”.

However, Acar argued that in many cases \(n = 2\) suffices, though this appears to be highly dependent on the commodity in question. Gas markets, for example, seem to work well with 2 factors and seasonality support, but maybe there are other more complicated cases which require larger \(n\). Bear in mind this work has not yet been merged to the main ORE branch, but from Acar's talk it seems to be progressing quite well and should land soon.

Figure 5: Two factor models.

The master class finished with a presentation by Jake Ullman on a new LSEG tool called Risk Analytics Lab (RAL). It appeared to be extremely useful, and with some overlap in functionality with what we are trying to do in ORE Studio. Where they differ, of course, is that RAL targets the professional user which plenty of domain knowledge, and provides all of the professional infrastructure one requires to drive ORE in real business use cases — e.g. a wealth of market data feeds, access to a Quant team and the like. ORE Studio instead targets the student and the apprentice — those who are trying to master the domain and the tool simultaneously and are not able to access all of the required market data needed to drive these features.

Figure 8: Risk Analytics Lab demo.

As I do not have access to RAL I won't comment too much on it, other than it seems to be a very user friendly tool and provides a lot of useful functionality such as P&L Attribution. In addition, it seems to integrate really well with Jupyter, so you can bring all of your python tools to bear and easily extend it as required as well as integrating it with the existing quant toolkits that most Tier 1 banks already have. One can imagine the SWIG work has been driven by a large extent to initiatives such as RAL, which is great to see.

Emily Prince gave some perspective on the topic of AI and the quant world. Overall the presentation was measured and realistic — not entirely sure why, but it reminded me of the tone of de Prado's book, if not the content (Advances in Financial Machine Learning). The gist of it is that, yes, it is a useful technology but, no, it is no silver bullet.

Figure 9: Prince's keynote on AI.

There are many things which will change dramatically, mainly those related to the more mechanistic aspects of the quant realm, and everyone will have to update their skills; there will be no blind use of AI to replace every developer and quant; and experience, judgement, taste and insight will continue to matter — dimensions which are very hard to replicate in AI. Interestingly, the increased use of AI may result in a need for more humans rather than less, but of a different skill set.

This panel was extremely interesting to those of us outside of LSEG because it lifted the veil on just how strategic ORE is to the entire organisation. The use of the risk engine is endemic now, and the direction of travel seems to be obvious; in an ideal world, it should be used everywhere where there is a good fit — and it seems to fit an awful lot of places. There is a clear move away from third party vendors, with a considerable effort to integrate new functionality in ORE which is not yet supported, so that migration away from third-party vendors is made possible. This is extremely good news for those of us outside the LSEG walled garden because it fills us with confidence that ORE is gaining more and more functionality over time. In addition, replacing battle hardened third party frameworks that have years (and in many cases decades) of market experience only demonstrates ORE is mature and very comprehensive.

Figure 10: Panel on LSEG’s Internal Adoption of ORE.

A special mention for Sanja Hukovic, not only because she was rather funny, but also because she and her team are doing a lot of the difficult work around model governance. To those outside, it seems that ORE is undergoing the difficult journey around model validation and governance; a complex journey, as anyone familiar with internal models in Tier 1 investment banks would tell you — probably shaking their heads due to PTSD. Yet this is vital work in such a highly regulated sector. In fact, it would probably be in LSEG's interest to make a public release of the documentation around these processes, including benchmarks, much like the purveyors of open weight LLMs release model cards and detailed white papers. Such an approach would certainly do no harm to ORE adoption at the highest levels.

When I saw the agenda I assumed this "talk" would have had a better fit with the morning Masterclass sessions since it appeared more low-level and nerd-oriented rather than business focused. Contrary to my expectations, rather than a talk it was a panel on the business side of optimisation and performance; and it was riveting.

Figure 11: Panel on Performance Optimisation and Run-time Considerations for ORE.

The panel discussed using ORE as a intraday pricing engine, something I suspected was possible but had no evidence for. Since my background is specifically Intraday Risk and Analytics development, I was extremely keen to hear an experience report on this front. I was even happier with what I heard: industry confirmation on the validity of ORE for this use case — particularly with large population sizes (~80M trades in a day) and fairly quick valuation ticks (every 5 minutes). Even more fascinating was that the setup was not yet making use of AAD nor GPU support, bot already mainlined.

Peter Caspers also provided some colour with implementation-level details on the performance optimisations that have been made so far — and, though I could not fully parse all of his content, what I could understand was very insightful, as it always is with Peter. I'll summarise the key points straight from Peter's slides:

• Multithreading: It is possible to make use of multithreading for specific valuation cases.
• AMC: Improvements to the American MonteCarlo engine in the context of the exposure frameworks.
• AMC-CG: Rewrite of AMC based on Computation Graph.
• AAD: improvements to the AAD implementation.
• GPU: more work on the GPU backend, focusing on T0 Analytics Exotics and XVA Sensis / Stress.

More of a pitch to the many potential customers, but also a great demonstration of the power of the overall approach, this session shed some light into a partnership between Anthropic and LSEG. Via the swiss-army knife of LLM protocols, MCP, it is possible to access LSEG's offering within Claude. This means that users with LSEG subscriptions can integrate a lot of their LLM workflow with the wealth of functionality available within LSEGs walled garden. Of course, for those of us outside it, this is not immediately useful — other than demonstrating the power of integrating ORE with LLMs, such as those behind Claude Code. Nevertheless, what was demonstrated appear to be the future, though already available in the present: asking Claude to retrieve risk numbers, massaging data into rich reports via APIs and the like. My dream is to do something similar to this in ORE Studio, but using llama.cpp and a local model such as a recent Qwen.

Continuing on the topic of AI and ORE, this panel provided a lot of industry insight on the direction of travel. Much like Prince, their view is nuanced and focused a lot more on the possibilities in this brand new world — as well as the risks — rather than your typical Silicon Valley, "boil the oceans and the sky is blue" approach. I am not sure if it is just the differences between the British versus American takes, but I always feel like the British version is the more realistic for the here and now and the American approach is always trying to sell us some AGI agentic future that seems hard to even imagine what it means in practice. So it was reassuring to hear from those in the front lines, running large desks, on how they are using AI in practice. Gordon Lee in particular was simultaneously very funny, very energetic and yet very sensible in his approach and views. It is still early days; the technology is extremely promising and much can already be done but — as with all technological revolutions — there are dangerous pitfalls awaiting those who do not apply it sensibly.

This session had some of the hallmarks of a "boring reg talk", but was unexpectedly interesting. My main take-away from it is that ISDA (and likely other regulators and standard organisations) are starting to see ORE as the "neutral" risk model. This means whenever you need to talk risk, methodologies and numbers, it helps a lot to have a risk engine we can all use and experiment with. A lingua franca of risk modeling, if you will. One can imagine this will be the direction of travel.

The final session of the day was a laundry list by Peter and James of the latest releases of ORE. In truth, we don't really need latest and greatest in ORE Studio, given that so much of the framework code is still yet to be written, but hearing of the new release is still important to us as a way of measuring the velocity of ORE. As it happens, v16 seems to be packed full of goodies, and it will hopefully be released soon. My notes from the slides captured the following, which I will dump more or less verbatim:

• New Instruments:
  • Swaption Straddles as a single trade
  • Cross-currency
  • Flexi-Swap and Cross-currency Bermudan Swaptions
  • New range accrual variation
  • Rate digital option
  • Dual European Binary Option
  • Cross-Currency support for CommoditySwap
• XVA:
  • LocalVol support for FX in exposure simulations
  • Speed up of MC exposure simulation, scenario generation and fast fx forward, vanilla swap engines
  • Review of inflation simulation framework
  • Speed up of cube reading / writing
• Pricing:
  • Heston model for scripted trade pricing
  • SVI for equity, fx, commodity, credit vol surfaces
  • Convexity adjustments for EquityTRS and BondTRS
  • Optionally use effective volatilities in market cap surfaces
  • Include conditional fee paid on exercise for swaption pricing
• Market Data:
  • Support for rebasing of inflation indices
  • Update single name CDS options to current conventions
  • Quoted commodity calendar spread options
  • Wildcards for zero curve spreads
• Update to latest QuantLib 1.42.

I did take copious notes during the presentation, but to be honest, I would just be presenting here a poor impersonation of the User Guide. So let's all wait for the latest release to come out, and instead proceed to the conclusions.