Genius Mathematics Consultants

Building a production-grade options pricing library has traditionally been one of the most demanding and time consuming tasks in quantitative finance. Often financial services firms will have as many as three such libraries: one for front office pricing, one for market risk calculation and one for independent validation of the others. They must be accurate, robust and flexible.

Recent advances in AI-assisted development tools such as Visual Studio 2026 and GitHub Copilot have fundamentally changed how these systems can be built. Instead of manually implementing and checking tens of thousands of lines of code, developers can now guide AI to generate complete pricing libraries, including curve and market data infrastructure.

This approach dramatically accelerates development, while potentially raising some new issues around code correctness and validation. However, these concerns can be well mitigated by using AI to generate libraries of unit tests, and generating more than one pricing model for cross-checking.

Step 1: Install Visual Studio 2026 and enable GitHub Copilot

Although there are many IDEs, AI models and coding assistants available, I’m going to focus on Visual Studio 2026 and Github Copilot, which is fully integrated into Visual Studio. Visual Studio is a full-featured professional IDE, and can be downloaded for free in the form of the community edition. Github Copilot Pro requires a small monthly fee to avoid hitting a usage cap, but is inexpensive. The first step is to install Visual Studio 2026 and subscribe to GitHub Copilot. Github Copilot allows selection of many different AI models including ChatGPT and Claude.

I’d recommend using either C# or C++ for a pricing library due to the faster execution speed for numeric models. The main drawcard of python is faster/easier human development and maintenance – an advantage less important when using AI code generation.

When using Copilot to generate code, it’s a good idea to give it specific instructions about how you want the code structured or modularised. For example, why not tell it to create a volatility class which default to “constant vol”. That way, if in the future you want to implement a local or stochastic vol model, you can just augment this class and the rest of the pricing code will still work. If at some point you want to manually check the correctness of any piece of the code, having the code structured in modular way that you find clear is going to make this process faster.

Step 2: Use AI to generate curve objects, market data infrastructure and trade loading/parsing functionality

Before pricing any options, the pricing library must be able to create curve objects representing interest rates, FX forward curves, discount factors, and other market inputs. The curve objects need to have appropriate interpolation functions defined. Volatility surface construction and interpolation is slightly involved – though potentially much faster when using Copilot. If you just want to specify the volatility directly, you can skip this aspect for now. If required, now is also the time to create code to load and parse trade data.

Step 3: Use AI to generate a Monte Carlo pricing engine

Where I would suggest beginning is to ask Github Copilot to generate a Monte Carlo pricing engine. This is because Monte Carlo can price all kinds of options. While slower than analytic pricing models (when they exist), it can be used as a validation tool to cross check the faster models. Make sure you tell Copilot to make it multithreaded!

Start with European options, and one step at a time add functionality for Asian payoffs, barriers, and early exercise (Longstaff-Schwarz).

Step 4: Use AI to generate analytic pricing models

While Monte Carlo is extremely versatile, it’s also slow and sometimes has numerical issues. The next step is to generate analytic or otherwise faster models:

1. Black Scholes vanilla pricer (of course)
2. The analytic Black-Scholes barrier equations
3. Method of moments for Asian options (not an exact model, but good enough for many purposes)
4. Binomial tree model for American options / early exercise

Step 5: Use AI to generate comprehensive unit tests

One of the most powerful uses of AI in building pricing libraries is automated validation. Github Copilot can rapidly generate long lists of unit tests. Hundreds or even thousands of tests can be created quickly. You want to focus on:

1. Checking that the Monte Carlo pricer agrees with the analytic or faster models for a comprehensive set of combinations of trade parameters
2. Checking special or corner cases such as:

• An American call with no dividends has the same price as a European call
• An American call should be exercised before a large dividend
• A knock-out option with spot already breaching the barrier should have value 0 (and likewise a knock-in should have the same value as a vanilla)
• And Asian option with only one averaging date at maturity should equal vanilla

Once these unit tests have been created, it just takes a few clicks to test them all again after new code changes.

Step 6: Use GitHub Copilot to generate documentation

It must be said that the necessity of documentation may be reduced when you can at any time ask Copilot to explain a part of the code for you!

But if you do require documentation of the pricing library, either for regulatory purposes or for other staff without access to the source code, Copilot will do that for you in seconds.

GitHub Copilot can generate complete documentation for the pricing library automatically, but be sure to give it detailed instructions about the format and content you require for the documentation. For example, you could ask it to include a section for each model describing pros/cons/limitations of the choice of pricing model.

Conclusion

AI tools such as Visual Studio 2026 and GitHub Copilot have transformed how production-grade options pricing libraries can be built.

Instead of manually implementing every model and unit test, developers can guide AI to generate complete pricing libraries, curve infrastructure, trade loading and unit test frameworks.

In this example, Monte Carlo serves as a reference model, while analytic and tree models provide more efficient pricing. AI-generated unit tests give confidence around model correctness at a fraction of the time cost of manually validating the entire library.

The result is a comprehensive pricing library that can be developed dramatically faster than traditional manually implemented systems.

In a previous article we discussed the unexpected complexities of trying to take advantage of cross-exchange arbitrages. In this article we’ll focus on triangular arbitrages either on a single exchange or between multiple exchanges.

A triangular arbitrage is where we convert currencies \(C_1 \to C_2 \to C_3 \to C_1\). If the exchange rates satisfy \(R_{12}R_{23}R_{31} > 1\), then we end up with more of \(C_1\) than we started with.

We can formulate this as a graph theory problem as follows. Taking the logarithm of both sides gives

\[\text{log}(R_{12})+\text{log}(R_{23})+\text{log}(R_{31}) > 0.\]

Let’s construct a complete graph where the vertices are the currencies \(C_1,C_2,C_3,\ldots\), and the edge between currencies \(C_i\) and \(C_j\) is \(\text{log}(R_{ij})\).

We’re interested in finding cycles where the sum of the edges is greater than 0. In fact, despite the name “triangular arbitrage”, there’s no reason to restrict ourselves to a cycle involving only three currencies. If we can find an arbitrage arising from a cycle of more than three currencies, that’s potentially exploitable as well.

It turns out that we have good algorithms, such as the Bellman-Ford algorithm, which can compute the shortest or longest paths from all vertices to all other vertices in a graph.

Challenges in practice

Just like in the previous article, this idealised model encounters several complexities when you try to apply it in practice:

• Each edge should actually be replaced by two edges representing bid and ask, for example \(R^{\text{bid}}_{12}\) and \(R^{\text{ask}}_{12}\).
• Due to slippage, the graph weights may need to depend on trade size.
• The edges need to be adjusted by the trading fees
• Latency makes the graph weights stochastic, meaning they need to be modelled by some appropriately chosen model
• In the case that you place limit orders, partial execution risk is far greater due to the larger number of trades involved

In essence this problem has more moving parts, but is otherwise quite similar to the cross-exchange arbitrage we previously considered. The main difference is we now have a large number of stochastic equations to formulate and calibrate to the data (one for each edge). Conceptually, it’s not too different.

Note also that 1) arbitrage opportunities may exist only briefly, and 2) the edge weights change constantly. Thus the algorithm needs to be re-run continuously. The efficiency of the algorithm is therefore paramount to take advantage of arbitrage opportunities before they disappear, and reduce the latency.

You might think that taking advantage of a price discrepancy between venues sounds pretty simple – if the prices aren’t the same buy at the low exchange and sell at the high exchange. It seems entirely simple and totally risk free! Unfortunately, and as we’ll see in this article, the reality is neither simple or risk free.

The complexities of execution

The first things we need to talk about which deviates from the simple picture above, are fees, slippage and the bid-ask spread. If the bid on exchange A is higher than the ask on exchange B, \(\text{Bid}_A > \text{Ask}_B\), then the profit is actually

\[\text{profit} = \text{Bid}_A – \text{Ask}_B – \text{fees} – \text{slippage}.\]

The slippage (price movement when we transact a volume larger than the first order book entry) contains a component from each exchange, and must be calculated from the order book data. Alternatively, we could drop the slippage term in this equation and instead replace the bid and ask with their volume weighted average prices (VWAP).

However, there’s still more to consider here – we have to consider latency and price movement. If an arbitrage opportunity enters existence at time \(t\), your two trades aren’t actually executed until times \(t+L_A\) and \(t+L_B\), where the latencies \(L_A\) and \(L_B\) can be different and consist of things like:

• The time between an arbitrage opportunity entering existence on the exchanges, and the information reaching your system
• The time taken for your system to process the data and become aware of the opportunity
• The time taken for your buy/sell orders to reach the exchanges
• The time taken for your orders to be processed and executed by the exchanges

Adverse price movement may occur during the latency periods, leading to the sum of the two trades no longer being profitable.

No free lunch

Now you may be thinking – what if I only post limit orders? Then the worst case scenario is that my trades don’t execute and I lose nothing!

But hold on, that’s not true – the worst case scenario is actually that one of the trades executes and the other doesn’t – leaving you holding inventory you didn’t want, whose value may fall.

To avoid this difficulty, cross-venue arbitrage algorithms often use market orders. Although this means the two trades could lose money, it also ensures that the trades always execute, and execute quickly, which reduces adverse price movement risk.

What this means is that, contrary to what you might have assumed, there is no risk-free way to try to exploit cross-exchange arbitrage. It also means that price prediction and probabilistic modelling becomes a significant part of any cross-exchange arbitrage system.

Probabilistic modelling and machine learning

As we’ve seen, by the time your system detects an arbitrage, the relevant prices are already stale. And the prices may move still further by the time your orders are executed on the exchange. In fact our profit equation is now

\[\text{profit} = \text{Bid}_A (t+L_A) – \text{Ask}_B (t+L_B) – \text{fees} – \text{slippage},\]

where the bid and ask functions are random variables. Also a random variable is the slippage, which should really be separated into \( \text{slippage} = \text{slippage}_A + \text{slippage}_B\).

A simple way to model the price at a time in the future is to assume a normal model

\[dP = \sigma dW,\]

where \(\sigma\) is the volatility and \(W\) is a Weiner process (Brownian motion). Now you may object that market prices are often modelled using geometric Brownian motion, where the price moves also get bigger when the price gets bigger. But keep in mind that as long as a normal model is periodically recalibrated (after price has changed substantially), this effect is captured by a normal model anyway. By recalibrating \(/sigma\) to the most recent data, we naturally arrive at the idea of a profitability threshold, where the trades are only executed if the observed arbitrage is sufficiently large relative to recent volatility.

Of course, more complex models are possible, including models that try to predict price movement by looking at volume imbalances on the order book, models that use trends/momentum or mean reversion, and models that attempt to use machine learning on a large number of signals. To undertake this kind of project involves both 1) developing a theoretical model, and 2) calibrating the model to recent historical data.

If your trades are large enough that slippage becomes significant, you would also want to model and calibrate optimal trade size. And if you were to use limit orders, you’d want to model the probability that an order would be filled and estimate when the trade would be filled.

Conclusion

Cross-exchange arbitrage appears simple and risk-free, but once fees, slippage, latency, and execution risk are taken into account, it’s a far more subtle and mathematically involved problem than it at first appears. It becomes a probabilistic trading strategy rather than a deterministic one, and it carries risk.

The role of the arbitrage detection algorithm is not simply to identify price differences, but to estimate expected profit under uncertainty. This requires careful modelling of order book dynamics, execution latency, and price movement.

See also our article on triangular arbitrage.

You’re probably aware that modern trading firms can utilize mathematical models and algorithms to make faster, more informed, and more profitable decisions, and you may be interested in increasing the sophistication of your own trading infrastructure. However, you might be unclear where to begin, which techniques are most relevant, or how to implement them in a way that produces measurable improvements rather than theoretical complexity. Building robust quantitative trading systems requires not only mathematical and statistical expertise, but also careful calibration with real data, and integration with execution workflows and risk management processes. Here are a number of applications of quantitative models to the world of trading to get you started!

• Optimal execution algorithm – Construct a statistically calibrated execution model (e.g. based on Almgren–Chriss or related frameworks), fitted to your historical trade and order book data, to determine optimal trade slicing and timing to minimise market impact and slippage.
• Trading algorithms – machine learning methods such as ridge regression methods to test signals, optimize signal weighting, and statistically optimize decision making.
• Liquidity and slippage prediction engine – Develop predictive models that estimate expected slippage and available liquidity as a function of trade size, volatility, order book structure, and market regime. This enables better pre-trade decision-making and more accurate transaction cost modelling.
• Cross-venue arbitrage detection algorithm – Build a real-time system to monitor price discrepancies across exchanges and trading venues, identifying statistically significant arbitrage opportunities while accounting for execution latency, transaction costs, and liquidity constraints.
• Anomaly detection engine for trading signals and market data – Implement statistical and machine learning methods to identify data feed errors, model failures, or abnormal trading signal behaviour before they can lead to incorrect decisions or financial losses.
• Market regime detection engine – Use statistical regime-switching models to identify shifts in market conditions such as volatility spikes, liquidity deterioration, or trend vs mean-reversion regimes. This allows trading strategies and risk models to adapt dynamically.
• Pricing engine for illiquid or complex assets – Develop fair-value models for instruments lacking reliable market prices, using Monte Carlo simulation, or market factor fitting approaches.
• Option pricing and volatility modelling infrastructure – Build or extend your options pricing capability including volatility surface construction, calibration of local or stochastic volatility models, and versatile numerical pricing methods like Monte Carlo.
• Independent model validation and model documentation – Perform rigorous validation of existing pricing, risk, or trading models, including correctness verification, stress testing, numerical stability analysis, and preparation of clear documentation describing model assumptions, limitations, and behaviour.
• Market risk modelling and Value-at-Risk calculations – Implement robust VaR and risk analytics frameworks, including historical simulation, Monte Carlo methods, and stress testing, providing accurate measurement of portfolio risk and tail exposure.

Legal disputes, regulatory investigations, and financial litigation often turn on technical details: pricing models, risk calculations, valuation assumptions, statistical methods, and quantitative systems. Legal outcomes can depend critically on whether the underlying mathematics and models are technically sound.

We provide expert testimony and independent consulting and litigation support services for law firms, legal teams, and expert witnesses requiring specialist support in mathematics, quantitative finance, and financial risk.

Quantitative support for litigation and regulatory matters

Modern legal disputes in the financial services frequently involve derivatives pricing disagreements, alleged model errors or mis-calibration, risk models used for capital, automated or AI-based decision systems, statistical claims requiring scrutiny, and regulatory expectations around model governance and validation.

These matters require deep technical analysis. General financial expertise is often insufficient. What is needed is expert quantitative insight: the ability to reconstruct the mathematics, identify hidden assumptions, test internal consistency, and assess whether conclusions are supported by the underlying models.

How we work with law firms and expert witnesses

Our role is to provide independent technical analysis and clarity.

We support lawyers and expert witnesses by analysing quantitative models and calculations used by banks, funds, or vendors; identifying incorrect assumptions, implementation errors, or conceptual flaws; assessing whether the models behave as claimed under realistic conditions; evaluating whether methodologies align with regulatory or industry standards; and translating complex mathematical findings into clear, structured explanations suitable for legal and expert reports.

This work is commonly used in litigation, disputes, regulatory responses, internal investigations, expert witness preparation, and early-stage technical assessments before proceedings escalate.

Areas of expertise

Mathematics and statistics
Probability and differential equations, coding and algorithms, numerical methods and approximation error, statistical inference, misuse of data, sensitivity analysis, and robustness testing.

Quantitative finance
Market risk and VaR calculation, derivatives pricing including interest rate, FX and equity options, structured products, and exotics; operational risk modelling; credit and liquidity risk models; reconciliation disputes; and analysis of model assumptions versus real-world behaviour.

Financial risk and model governance
Model validation and independent challenge, risk systems, AI and automated decision tools in finance, and alignment with regulatory expectations in disputed or investigative contexts.

Independent expert analysis, not advocacy

We work independently of banks, vendors, and large consulting firms. My role is not advocacy, but objective technical assessment.

An alternative to large consulting firms

Large consulting firms are frequently engaged in financial disputes and regulatory matters, but their operating model is not always well suited to focused, technically precise analysis.

Law firms often require clear, independent quantitative insight rather than large delivery teams, generic reporting, or broad advisory scopes. Major consulting firms typically operate with higher overheads and layered staffing models, which can dramatically increase cost without improving technical clarity.

Our consulting approach is deliberately different. I work as a single, independent specialist, providing direct analysis in mathematics, quantitative finance, and financial risk. Engagements are narrowly scoped and focused on the specific quantitative questions relevant to the matter.

For many legal teams, this offers greater proportionality, clearer accountability, faster turnaround, and substantially lower cost than large consulting engagements.

When legal teams engage quantitative experts

Law firms and expert witnesses typically engage this type of support when a case hinges on technical modelling or financial calculations, internal explanations from financial institutions do not withstand scrutiny, expert opinions require rigorous quantitative backing, regulators or counterparties raise modelling objections, or early independent analysis could materially affect legal strategy.

Identifying technical weaknesses early often changes the trajectory of a matter.

Getting in touch

If you are a lawyer or expert witness working on a matter involving mathematics, quantitative finance, or financial risk and require independent technical analysis, contact us to discuss how we can help.

Artificial intelligence is transforming every industry, from finance to healthcare to education. As organisations increase their reliance on AI models, the accuracy, robustness, and reliability of AI generated models and processes become critical. As AI becomes increasingly embedded in workflows, failures can cause massive operational losses, regulatory breaches, and reputational damage.

At Genius Mathematics Consultants, we specialise in independent model validation services, AI model audit and AI risk management. We analyse, test, and certify AI systems and AI generated work to ensure that they behave correctly, consistently, and safely.

What Is AI Model Validation?

The capabilities of AI are truly impressive, and improving every day. Yet, all of us have experienced AI producing work that contains mistakes. This is simple a result of the fact that current generation AIs simply generate text that is “likely” to be true, based on the data it’s been trained on. While the latest AI models do attempt to incorporate logic engines that should help reduce this, their accuracy can still fail in critical ways.

In many industries, particularly financial services, careful model validation by expert quantitative staff has long been a necessity. But the capability of AI to rapidly generate plausible but not always reliable work expands this requirement by an order of magnitude. Effective AI governance thus requires that all AI generated work be carefully checked and verified. But what is the fastest and most efficient way to do this?

How to validate AI models

Validating AI generated work requires a multi-layered approach, consisting of at least these steps:

• Review of the methodology the AI has proposed
• Manual inspection of the code to ensure faultless agreement with the proposed methodology
• Benchmarking the model against independent benchmark models to check for agreement within some tolerance
• Checking the behaviour of the model for all qualitatively different cases, including rare, unusual “stress scenarios”, to ensure it behaves as expected under all scenarios.
• Passing the AI generated work to alternate AIs for independent checking. It’s less likely that multiple AIs will make the same mistake. As always, it’s good to give the AI specific instructions on how to check the code, to increase the quality of the result.

A simple case study

This case study concerns option pricing models in quantitative finance, but the principles extend to validating many kinds of AI generated work.

For a recent project we needed to build a Monte Carlo model in C# to price financial options. We needed the model to be able to handle early exercise, barrier and Asian option variants. The model used the Longstaff-Schwarz method to handle early exercise. To build this code manually might have taken a number of weeks. Using AI, it took 1-2 days.

To validate, we set up a large number of quite comprehensive unit tests to validate the code against independent models. In addition to the required MC code, we had the AI generate a number of auxiliary models to benchmark the Monte Carlo code against. The pricing of barrier options could be checked against the closed form Black Scholes barrier equations, the pricing of American options could be checked against a binomial tree model, and the pricing of Asian options could be checked against the method of moments. We also used AI to generate the comparison models. Although we were checking AI generated code against AI generated code, as the comparison models are conceptually very different to Monte Carlo, the chances of both pieces of code being wrong in the same way is very small.

Secondly, we set up a second set of unit tests for stress testing and edge-case testing. This included a range of unit tests where the correct output of the code is obvious. For example, an already knocked-in option should have the same price as a vanilla option, an American call is never optimal to early exercise, and so on.

Looking for AI model validation, audit and risk management services?

Then we’ve got you covered. Contact us to get the ball rolling.

Is your AI infrastructure audit-ready? Don’t wait for a model failure to uncover hidden risks.

When you think about financial consulting firms, you probably think about huge firms like EY, Deloitte, KPMG, PwC and McKinsey. But did you know that it’s possible to get superior expertise, more conveniently and with faster execution, all at dramatically lower cost than big consulting firms?

This consulting practice is deliberately different. We specialise in all technical and quantitative work, in both financial services and in science and engineering, right up to PhD research level — delivered personally, efficiently, and without the overheads of a large corporate machine.

Value for money

Big consulting firms:

• High overheads due to layers of partners, managers, office infrastructure and expensive real estate.
• Day rates often reflect branding and corporate structure, not actual work.
• You may meet a senior expert at the proposal stage, but most work is done by juniors paid a small fraction of the fee you pay.

Our consulting practice:

• Lean structure with no inflated corporate costs and no real estate costs.
• You pay only for the hours worked by PhD qualified experts
• No outsourcing to cheaper or junior employees

What this means for you:
Dramatically lower costs, yet more experience and expertise.

Quality and depth of expertise

Big consulting firms:

• Rely more on branding, image and politics than on rigorous work
• Technical work often handled by consultants with limited specialist training.
• Reliance on frameworks and templates rather than deep analysis.
• Documentation frequency incomplete, confusing or using obscure legalistic language, or no documentation at all.

Our consulting practice:

• Fully specialised and PhD-qualified in mathematics, coding, problem solving and quantitative finance.
• Tailored, mathematically rigorous solutions rather than generic frameworks.
• Clear and organised documentation

What this means for you:
You get bespoke, focused and technically accurate solutions for complex problems, explained and documented clearly.

Convenience, speed, and lack of bureaucracy

Big consulting firms:

• Complex onboarding, resourcing, and reporting processes.
• Slow adaptation to changing project needs or new information.
• Multiple communication layers between the client and actual modeller.
• The person you speak with may not be the person producing the work.
• Delays of weeks or months while other work is prioritised
• Small, specialised technical tasks are often uneconomical for them.

Our consulting practice:

• Direct, fast, and responsive — you deal with the person actually doing the work.
• Flexible and able to pivot quickly as requirements evolve.
• No unnecessary bureaucracy or internal approval cycles.
• Clear accountability and ownership of work delivered.
• Ideal for both small targeted projects and complex long-term engagements.

What this means for you:
Faster turnaround, clear communication, and you get exactly the expertise you need, in the format that suits your business.

Independence and objectivity

Big consulting firms:

• May have partnerships or commercial agreements with software vendors.
• Recommendations can sometimes be influenced by internal business interests, and politics that serve the consulting firm rather than the needs of your business.

Our consulting practice:

• Fully independent, with no vendor alliances or incentives.
• No internal politics – only objective advice driven purely by a desire to help you succeed.

What this means for you:
Objective, unbiased solutions designed solely around your needs.

The obvious choice

Looking to partner with a consulting firm? Contact Us Today to get the ball rolling.

At Genius Mathematics Consultants, we help businesses, researchers, and financial professionals harness the power of artificial intelligence models like ChatGPT, Claude and Google Gemini. Artificial intelligence is revolutionizing the way people engage in mathematical problem solving, coding, research and quantitative finance. As extremely impressive but imperfect tools, it’s important that they are guided by someone with the appropriate expertise in the underlying subject matter. AI assisted working is the future, and we can help you get started.

Mathematical Problem Solving with AI

Artificial intelligence has progressed rapidly and is now useful even for advanced mathematical and symbolic reasoning, theorem exploration and numerical analysis. Its ability to rapidly survey many sources, and combine and reformat the results to answer your query will create a revolution in research. Gone too is the time consuming task of formatting equations in Latex, as artificial intelligence now does this for you in a flash.

We help clients use these tools to dramatically improve efficiency, while ensuring results remain academically rigorous.

AI for Coding, Automation, and Algorithm Design

AI can now help developers write, debug and optimize code across multiple programming languages. At Genius Mathematics Consultants, we guide teams through AI-assisted algorithm design. We help you incorporate intelligent code automation without compromising the mathematical accuracy of your models or integrity of your software.

AI in Quantitative Finance

As a field focused on maths, coding and data processing, AI is going to revolutionise quantitative finance. Our consulting services cover deployment of AI for trading including researching and backtesting strategies, automated risk model validation for regulatory compliance, and rapidly building code to analyse and reformat trading book data..

We also utilize machine learning techniques such as machine learning trading strategies, option pricing using neural networks, and portfolio optimization using reinforcement learning. Our consultants can help you learn to use artificial intelligence to develop capabilities like these quickly and accurately.

Implementing AI in Your Organisation

Whether you’re exploring AI for the first time or wanting to delve deeper, we can help you develop a strategy to make AI work for your business. Our consultants can identify high-impact use cases, and take them from design to deployment. Our approach is collaborative and transparent. We don’t just deliver models — we help your organisation understand and control the technology behind them.

Why Work With Mathematics Consultants

Our consultants combine deep expertise in research level mathematics, coding, and quantitative finance. We bring cross-disciplinary experience to every engagement — leveraging artificial intelligence for everything from financial derivatives to engineering automation to symbolic reasoning for mathematical research. Every project is fully customized to align with your objectives, ensuring measurable results and long-term capability building.

We work with financial institutions, technology firms, and individual researchers who value both mathematical precision and innovative engineering.

Ready to integrate AI into your work?
Simply contact us to arrange a consultation on AI assisted problem solving, coding and quantitative modelling.

The problem with finite difference methods

If you’ve ever tried to calculate Greeks when pricing options using Monte Carlo, you’ve probably found that it’s both very slow, and also potentially inaccurate unless an enormous number of paths is used. There are two main reasons for this.

Firstly, calculating Greeks using finite differences requires that the pricing function be evaluated multiple times. For example, for a second order derivative like gamma, three evaluations of the pricing function are required. Monte Carlo pricers are already slow even when evaluated once, and having to evaluate them many more times to get the Greeks makes them many times slower again.

Secondly, since the step size needs to be small when calculating derivatives, the prices are likely very close together as well. When calculating the difference between two very similar values, you run the risk that you are just getting Monte Carlo noise. One could try to use a larger step size, so that the calculated difference is larger when compared against the noise, but the calculated value may then diverge from the true derivative.

You might also like to check out our article on the Longstaff-Schwarz method for pricing American options.

Algorithmic differentiation

You might have heard about algorithmic differentiation, and “adjoint” algorithmic differentiation – a technique for more efficiently and more accurately calculating Greeks for Monte Carlo pricing models. This technique allows derivatives to be calculated via repeated applications of the chain rule, without needing to evaluate the pricing function multiple times. Instead, one spends time manually (symbolically) differentiating some of the functions involved. However, you might have found that the explanations available on the internet tend to be quite abstract and much more confusing than they need to be. The purpose of this note is to give a clear and readable example of exactly how and why algorithmic differentiation works when applied to Monte Carlo options pricing.

Calculating delta and vega

The essence of a Monte Carlo option pricer is simple. The discounted payoff of the option is evaluated on each path \(i\), and then the present value \(P\) is simply the average:

\[PV = \frac{1}{N} \sum_i e^{-rT_i}\text{Payoff}(i).\]

Here \(T_i\) is the settlement date for the \(i^{th}\) path. Note that in general, for path dependent derivatives,

\[\text{Payoff(i)} = \text{Payoff}(S_0^i,…,S_N^i,T_i).\]

However, in many cases the payoff would only depend on \(S_N\).

Let’s suppose we want to calculate a derivative of \(PV\), say delta. By simply moving the derivative inside the summation we get

\[\frac{dPV}{dS_0} = \frac{1}{N} \sum_i \frac{d}{dS_0} \left( e^{-rT_i}\text{Payoff}(i) \right).\]

Let’s consider now calculating the term inside the summation for the \(i^{th}\) path, dropping the subscript \(i\) for simplicity. We start with the formula to generate the path. Each time step we calculate the value \(S\) of the underlying at the next step by some function

\[S_{n+1} = f(S_n, Z_n),\]

where \(Z_n\) is a random draw from a normal distribution. Let’s keep things simple by considering the case \(T_i = T\) for all \(i\) so we can pull the discount factor out the front. Then applying the chain rule we need to calculate

\[\frac{d}{dS_0} \left( \text{Payoff} \right) = \sum_k \frac{d\text{Payoff}}{dS_k} \frac{dS_k}{dS_0}.\]

The derivative of the payoff \(\frac{d\text{Payoff}}{dS_k}\) we’ll look at in the next sections. This term needs to be calculated individually for each kind of derivative in the trading book (this is one downside of algorithmic differentiation, as it increases the complexity of the code and the likelihood of errors). Let’s now examine the final term \(\frac{dS_k}{dS_0}\). The usual path generation calculation using geometric brownian motion is

\[S_{n+1} = S_n e^{(r-\frac{1}{2} \sigma^2) \delta t + \sigma \sqrt{\delta t} Z_n}.\]

Since the exponential term has no \(S\) dependence, this means we get simply

\[\frac{dS_k}{dS_0} = \frac{S_k}{S_0}.\]

This value can be calculated at the \(k^{th}\) time step and stored.

If we were calculating vega instead, we would get

\[\frac{d}{d\sigma} \left( \text{Payoff} \right) = \sum_k \frac{d\text{Payoff}}{dS_k} \frac{dS_k}{d\sigma}.\]

Then the final term is

\[ \frac{dS_{n+1}}{d\sigma} = S_{n+1} \left( -\sigma \,\delta t + \sqrt{\delta t}\, Z_n \right) \frac{S_{n+1}}{S_n} \cdot \frac{dS_n}{d\sigma}. \]

We have of course \(\frac{S_0}{\sigma} = 0\), and we calculate each successive value using the one before, storing the values to use at the end.

Vanilla options

The payoff of vanilla options only depends on the underlying at expiry. This means the derivatives with respect to \(S_k\) are all zero except the final one, which is

\[\frac{\text{dPayoff}_{Van}}{dS_N} = 1_{S_N > K} \]

for a call and

\[\frac{\text{dPayoff}_{Van}}{dS_N} = -1_{S_N< K} \]

for a put.

Barrier options

For barrier options we run into a problem where the derivative of the payoff with respect to \(S_k\) would seem to be zero, except for the case \(k=N\). This is because since each \(S_k\) is some finite distance from the barrier (assuming no breach yet), when you shift each one infinitesimally, you still get no barrier breach. But in reality, there is an increased probability of breach in between the time steps. To capture this, we need to use a Brownian bridge. We denote by

\[p_m = \text{exp}\left( -\frac{2(B-S_m)(B-S_{m+1})}{\sigma^2 \Delta t_m} \right) \]

the probability that the path breaches the barrier in between time steps \(\) and \(m+1\) (we assume an upper knockout barrier here). Then

\[ \text{Payoff} = \prod_{m=0}^{N-1} p_m \big(S_m,\, S_{m+1}\big) \text{Payoff}_{Van} \]

We can now easily differentiate this payoff with respect to \(S_m\) using the chain rule, a noting that we already calculated the derivatives of the second term in the previous section.

Gamma

A technical difficulty arises around using this method for gamma. If you think about the shape of the payoff of a vanilla option, it’s second derivative is zero everywhere except at the strike, where it could be thought of as infinite (or undefined). One simple way you can attempt to handle this issue is to slightly smooth the payoff function near the bend. Another approach is to not differentiate the payoff at the final step N, but instead differentiate it’s expectation one step earlier (which is simply the Black Scholes formula over one time step). This trick is sufficient to smooth out the kink in the payoff.

Adjoint Algorithmic Differentiation

There’s a slightly different approach which is more computationally efficient when you want to calculate a large number of derivatives with respect to many different variables. This is called “adjoint” algorithmic differentiation and it involves doing both a forward and a backward pass. The runtime of the forward method grows linearly with the number of derivatives required (O(m)), while the backwards method is essentially O(1). Let’s look again at our formula for delta. Suppose we have already done a forward pass which has generated the path values \(S_k\) for each k. The backward pass works like this:

We can already calculate \(\frac{d\mathrm{Payoff}}{dS_N}\), since it’s just the dependence of the payoff on the spot value at maturity. Of course, what we really want on the bottom here is \(S_0\). We step backwards one step by employing the chain rule like this:

\[ \frac{d\mathrm{Payoff}}{dS_{N-1}} = \frac{d\mathrm{Payoff}}{dS_{N}} \frac{dS_N}{dS_{N-1}}. \]

We can then do it again:

\[ \frac{d\mathrm{Payoff}}{dS_{N-2}} = \frac{d\mathrm{Payoff}}{dS_{N-1}} \frac{dS_N}{dS_{N-2}}. \]

Continuing, we eventually arrive at an expression for \(\frac{d\mathrm{Payoff}}{dS_{0}}\).

Model validation is a strict regulatory requirement for many financial services businesses, essential for risk management and front office profitability. It’s also critical for many other industries as well. In the medical device, aviation and mining industries, model failure could not only lead to financial loss, but cost lives. In so many industries, models must be thoroughly validated both before deployment, and at regular intervals after deployment. They must also be stress tested on unusual scenarios to ensure they will remain robust.

In order to speed up and broaden the scope of model validation, many organisations are considering building automated model validation tools. In this article, we’ll look at how automated model validation differs from manual validation, and how both are an essential part of a validation ecosystem.

What is model validation?

Model validation is a process to regularly test and monitor mathematical models. This spans the conceptual soundness of the model, the correctness of the coding implementation, and the interactions between systems such as data interfaces. The context could be option pricing or risk models in finance, machine learning models to detect mineral deposits in mining, automated trading systems, or medical monitoring devices. Increasingly, AI and machine learning models need to be validated. And of course, the wide-spread use of impressive but error-prone AI tools like ChatGPT necessitates a whole new world of model validation. The process typically involves:

• Reviewing the correctness of the mathematical methodology and documenting it
• Assessing the any model limitations or boundaries of validity
• Building an independent model, either of the same methodology or a different one, and ensuring the output of both models are within some acceptable tolerance
• Monitoring the ongoing appropriateness of the model considering changes in downstream and upstream systems, and changes in the environment the model operates in
• Stress testing the model to ensure robustness under unusual scenarios (eg financial downturns)
• Documenting all findings

What is automated model validation?

Automated model validation is the use of software tools and frameworks to autonomously and systematically test and monitor models. Typically these tools:

• Automatically pull in and format data from source systems (where a human validator might need to examine a GUI one number at a time)
• Verify huge numbers of model outputs by comparing against independent model implementations

Benefits of automated model validation

A downside of automated model validation systems is they may require a significant initial investment to build. So what are the advantages?

• Once set up, automated model validation is far less time intensive than model validation. An automated system could examine thousands of trades in a trading book, where a manual validator has time to check a dozen.
• Automated systems make it easy to quickly retest the models after system updates, or set up regular periodic validations or continuous monitoring.
• Scalability: automated systems can have a scale beyond the scope of human validators
• Automated systems may free up human validators to focus more on conceptual model review
• To the extent that less manual work is required, they may reduce costs.

Benefits of manual model validation

• Manual validation involves reviewing the assumptions and methodology of the model, often in a changing environment. This is something which doesn’t happen at all with automated model validation.
• How can you be sure the independent implementation used by the automated validation system is correct? To an extent, automated validation actually results in two models that need to be validated. And where both models have similar assumptions or methodologies, it’s entirely possible for the models to agree and both be wrong.
• Manual model validators also provide another very important function – the preparation of detailed validation reports clarifying the methodology, assumptions and limitations of the model where documentation is usually sorely lacking.
• Human validators can improve model design, not just test model outputs.
• Credibility with the regulator: in the case of regulated industries, human expert analysis may be considered essential.

Why a hybrid approach is best practice

The best approach to model validation is a hybrid approach, combining manual model validation with automated model validation. This is where manual model validators carefully check model assumptions, work to improve and maintain the accuracy of the automated model, and produce high quality documentation about the models. At the same time, the automated system allows for much more frequent and large scale testing and monitoring of trades and models. Having found serious errors in models that had already been validated several times, this author can tell you that the need for expert validators will never go away.

We offer model validation consulting services, including both manual model validation and the design of automated model validation systems. Contact us to learn more.