Consulting and Expert Witness Services for Lawyers in Mathematics, Quantitative Finance, and Financial Risk

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.

Independent AI Model Validation Services: Mitigating Model Risk

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.

How Genius Mathematics Consultants Compares to Big Financial Consulting Firms

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.

Artificial Intelligence Consulting for Mathematical Problem Solving, Coding, and Quantitative Finance

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.

Algorithmic Differentiation: Fast Greeks in Monte Carlo Option Pricing

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}}\).

Automated Model Validation vs Manual Model Validation – Finding a Balance

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.

Vendor Trading Systems vs. Building In-House: Pros and Cons

Choosing between a vendor trading system and an in-house solution is one of the most important technology decisions banks, trading firms, and hedge funds make. This article explores the trade-offs and helps decision-makers navigate this complex choice – build or buy?

Should you build your own quantitative trading system in-house, or to pay ongoing licensing fees for a vendor trading platform such as Murex or Calypso? This decision has profound implications for the cost, flexibility, and competitiveness of your trading operations, and it’s not a decision that can be easily changed in the future.

Vendor trading systems will likely be faster to market, with faster access to extensive functionality, and models that have undergone many cycles of validation already. But any functionality you don’t need simply adds unnecessary complexity. Systems like Murex have a significant learning curve to set up and configure, with Murex technical support staff required to be hired at your firm. This is in additional to technical support staff at the vendor that you will be billed for. Adding your own models and functionality may be harder, more expensive or not possible at all. Model development and bug fixing is likely to be much faster with all source code in-house, leading to a more agile business. Model documentation can be maintained in-house, instead of being at the mercy of how conscientious the vendor has been with their documentation.

For regulated entities, vendor systems can make model validation and regulatory reporting more complex. Without source code access, determining what models are doing or how they are failing becomes a complex business problem, and demonstrating compliance to auditors and regulators more time consuming, which increases cost and operational risk.

In terms of cost, developing your own system might cost more initially, but vendor fees and hidden charges can easily be underestimated. These will have no expiry and will eventually accumulate to more than the cost of building your own system. Once you have signed on, moving away from the vendor setup would be so expensive that you’re at their mercy in terms of fees.

The interests of the vendor and your own firm are never entirely aligned. Vendors are juggling hundreds of clients. When engaging in model validation of the vendor systems, I’ve noticed that vendors are often reluctant to admit their systems have a fault. In a particularly egregious case, I saw a vendor deliberately obstruct model validation staff in order to avoid admitting there was a serious problem with their model. After months of fighting with the vendor, they finally fixed the fault and whole book got revalued.

Vendor Trading Systems (e.g., Murex, Calypso)

Pros:

  • Speed to market: Because vendor systems are already built, you will likely be operational sooner.
  • Broad functionality: Immediate access to a wide range of models and configuration options, including derivative pricing models and market risk models.
  • Model confidence: The models of very large vendors have been repeated validated by their clients, reducing the likelihood of faults.

Cons:

  • Very high licencing and maintenance costs: The cost of signing on is only the beginning, as vendors charge further fees for support staff, unlocking more advanced models or modules, and even fixing faults.
  • Vendor lock-in: once you have heavily invested in the vendor’s systems, it’s too expensive to change to another option. This gives you little negotiating power with the vendor.
  • Less flexibility: You’re largely limited to the existing functionality the system and any inherent design limitations.
  • Integration: The vendor systems must be integrated with your own
  • Unused Complexity: the broad functionality needed for the vendor’s many clients makes configuration and use more complicated, and increases the risk of model misconfiguration.
  • Model documentation: Although vendors provide documentation, the quality of this can vary. With no direct access to the source code, it can be challenging to determine what the models are doing.
  • Politics and misaligned interests: The vendor may be more focused on extracting money, juggling many other clients, and avoiding admitting to any faults with their systems, than in helping your business.

Building an In-House Trading System

Pros:

  • Fully customizable: An in-house system is tailored for exactly your requirements
  • Streamlined: No unused functionality adding complexity
  • Unique or cutting-edge: Instead of using the system everyone else is using, you can innovate for a competitive advantage.
  • Agility: Rapid implementation of fixes and new features with fewer layers of bureaucracy and go-betweens.
  • Cheaper: Likely cheaper in the long run, but with significant upfront costs.
  • Model documentation: you have direct access to the source code when questions arise about the behaviour of the models

Cons:

  • Longer time to market: The vendor solution can likely be operational sooner.
  • Required expertise: You may require more quantitative expertise in-house. However, you could alternatively partner with a suitable consulting firm.

At Genius Mathematics Consultants, we specialize in providing quant support to help firms design and implement in-house trading systems. Our consulting services span quantitative and algorithmic trading, derivative pricing models, and risk model design such as Market VaR calculations. We ensure that your technology not only runs efficiently but also meets regulatory standards. We bring the ability to translate cutting-edge research into reliable production code. By partnering with us, you gain access to flexible quant expertise that supports your team in building systems tailored to your strategies—without the cost and complexity of maintaining in-house quant staff. To learn more about how your business can partner with our consultants, Contact Us.

Ridge regression for Statistical Arbitrage in Crypto (pairs trading)

I previously wrote an article for Dorian Trader which explored using ridge regression to develop a trading strategy. The article showed how ridge regression helped prevent overfitting as compared to regular regression, and was often uncannily good at predicting the peaks and troughs of trading data. See the original article here.

I also created a follow up article for Crypto News testing the same strategy on cryptocurrencies.

In those articles, the strategy was limited to only using a single asset. That is, the signals used as inputs were calculated only from the price history of the same asset that we were trading. In this article, we’ll explore whether the price history of closely related assets can contain valuable predictive information. This could be, for example, stocks from a similar industry, or different crypto currencies, both of which tend to move together. This is usually called statistical arbitrage or pairs trading (but note that despite the name, one could do it with any number of related assets, not necessarily two).

The basic mechanism

Pairs trading or statistical arbitrage makes use of the tendency for two assets to move together. It may mean that when one asset moves, the other is more likely to follow suit. It may also mean that the further apart the two assets become, the more likely they are to converge together again.

When we applied ridge regression to the single asset case, we used moving averages and regression lines of various lengths as our main signals. Here, we will do the same, except that we will have an additional set of signals generated from the second asset. We will use three moving averages and three regression lines of different lengths, so the regression has a choice of using whichever is more predictive. You could also use more than three, especially initially, if you are unsure of how much time might elapse between divergence and convergence of the related assets.

The mechanism here is that by including moving averages of different lengths, a linear model like ridge regression can implicitly include their differences as well, so that it can capture how much each asset has diverged (up or down) compared to its earlier values. It also implicitly includes the difference between the divergence of the first asset and the divergence of the second asset, so that it can capture how much one asset has diverged relative to the other.

If we believe that there is a lag between divergence and convergence, we could consider introducing a lag between the signal calculation time and the time at which the ridge regression tries to predict the price. However, by including signals like moving averages calculated over a variety of time windows, the model will be able to automatically calculate a few lagged moving averages anyway (as these are a linear combination of existing moving averages).

An additional issue springs to mind in the two asset case, is that the two assets may have very different scales, and the ratio between the two could drift over time. For this reason, one might consider taking various ratios of the signals and including them as additional input signals:

  • For each asset, we can generate additional signals by taking the ratios of moving averages of different lengths, and the ratios of regression lines of different lengths.
  • We’ll also add the ratios of the same signal between the two assets. This will allow the ridge regression to track how much the the assets have diverged in terms of their ratio.

The reality is, if the data window is not too large, the scales of the assets won’t change too much over the data set, and the relevant ratios can be assumed constant and will be automatically captured by the coefficients chosen by the ridge regression. So one might make a case that it’s not necessary to include the ratios when fitting over a relatively small time window (we will use one week). However, I’ve chosen to include all the mentioned ratios anyway. If nothing else, being able to see the coefficients for these signals provides more insight into how the ridge regression is working.

At the moment the model trains only on the most recent week of data. Although more data might seem better, more recent data is more relevant and allows the model to adapt to recent market conditions.

Cryptocurrencies

We use one week of data ending on the 14th of August 2025, with the test set being approximately the final three hours of data.

It’s most likely that movements in the big coins are going to presage movements in the smaller coins, rather than the other way round. For this reason it’s most sensible to use BTC as an input when trying to predict ETH. Below we show the coefficients that the ridge regression has assigned to each of our signals.

RegLine5 = -0.707
RegLine20 = 0.509
RegLine50 = -0.403
MovAvg5 = -0.323
MovAvg20 = 0.185
MovAvg50 = 1.127
MovAvg5/20 = -0.442
MovAvg5/50 = 1.025
MovAvg20/50 = -0.674
RegLine5/20 = 0.055
RegLine5/50 = -0.205
RegLine20/50 = 0.129
Close_BTC-USD = 0.014
RegLine5_BTC-USD = -0.046
RegLine20_BTC-USD = 0.542
RegLine50_BTC-USD = -0.142
MovAvg5_BTC-USD = -0.051
MovAvg20_BTC-USD = -0.192
MovAvg50_BTC-USD = -0.235
MovAvg5/20_BTC-USD = 0.249
MovAvg5/50_BTC-USD = -0.496
MovAvg20/50_BTC-USD = 0.291
RegLine5/20_BTC-USD = 0.096
RegLine5/50_BTC-USD = -0.18
RegLine20/50_BTC-USD = 0.117
MovAvg5/5 = -0.555
MovAvg20/20 = 0.139
MovAvg50/50 = 0.116
Strategy profit = 107.596
Buy Hold profit = 19.161

The first 12 signals are all calculated from ETH price data. They consist of the linear regression lines (across three windows of different lengths), moving averages, ratios of the moving averages and ratios of the linear regression predictions. The following 12 signals are identical except calculated using BTC price data. The final three signals are the ratios of the the ETH moving averages to the BTC moving averages.

Since ridge regression tries to make the coefficients small when it doesn’t harm the predictive power too much, and the signals are scaled prior to fitting, one can to an extent judge the significance of each signal by the size of the coefficient.

  • The most significant ETH signals are the 50 minute moving average, and the ratio between the 5 and 50 minute moving averages. The other moving average ratios, and the regression lines, are also significant.
  • The BTC signals are less significant than the ETH signals with smaller coefficients, as you would expect. The most significant are the 20 minute regression line, and the ratio between the 5 and 50 minute moving average.
  • The ratio between the 5 minute BTC and 5 minute ETH moving average also makes a contribution.

Looking at the plot, we see what we often see with ridge regression – it can be very good at placing sell markers at the peaks, and buy markers at the troughs. This gives a visual representation of why the strategy profit is 107.6 while the buy and hold profit is only 19.2.

But how much impact is the second asset, BTC, having here?

Isolating the impact of the second asset

We naturally want to know how much predictive power is coming from the second asset (BTC), and how much is coming from ETH’s own price history. We can see from the size of the coefficients that the ETH price history is more significant than the BTC price history.

To further evaluate this question, we can omit the BTC signals and see how much the prediction / profitability degrades.

Now when we do this exercise, it’s important that we make the test and fit sets the same. This is because when the test set is outside of the data seen during fitting, it can be totally arbitrary and could favour any one of the models simply by chance. This makes comparison of different models very difficult. This might be mitigated by using a very large test set, which would have to be assumed to be representative of all future possibilities. However, this requires that a much larger amount of data be obtained, and the fact that market regimes change over time raises it’s own challenges. By using overlapping test and fit sets, we can test which of the three models can match the data most successfully, albeit without considering potential overfitting. In this case, I’ve used the entire week’s dataset for both testing and fitting (which is why the numbers are different from the previous section). For reference, the buy and hold profit was 945.3 in this case.

  • Fit and backtest the model using only ETH signals – Strategy profit = 1343.0, Rsquared = 0.011
  • Fit and backtest the model using both – Strategy profit =1556.5, Rsquared = 0.014

These numbers make a possible case that including the BTC signals improves the strategy. However, the case isn’t water tight due to the fact the including additional signals increases the opportunity for overfitting.

More than two assets

Statistical arbitrage, or the principles behind pairs trading, can work with any number of assets. For example, one could use a whole basket of stocks from the same industry. In the case of crypto trading, we can consider using other coins in our prediction. Movements in smaller coins are unlikely to have as big an impact as Bitcoin on the price of ETH. Let’s try the exercise again including the next four largest coins by market capitalization: XRP, BNB, SOL and DOGE.

Using five coins as additional signals: Strategy profit = 2051.7, Rsquared = 0.015

The strategy profit is distinctly higher than when using only ETH, and when using ETH and BTC as inputs. All of the coins had signals with decent sized coefficients, suggesting that the ridge regression found them significant. However, as mentioned already, overfitting is a concern here.

Risks of multi-asset strategies

It’s important to consider that a strategy involving the signals of other assets may be more dangerous than one involving only one asset. This is because although a group of assets may often move similarly, there’s the possibility for their behaviour to significantly diverge for periods of time. For example, two crypto coins may often move similarly as they are both affected by general sentiment about crypto. But if one coin were to experience significant growth or decline based on events pertaining only to that asset, the relationship may cease to hold. Safeguards need to be added to the strategy to enable it to disregard the signals of other assets under certain circumstances.

Option Pricing using Neural Networks

I recently wrote an article for Dorian Trader on using a neural network to replicate option pricing models. The idea behind using neural networks in option pricing, is that while the original numerical model might be slow, the neural network (once trained) is lightning fast at pricing options.

In that article, I fitted a neural network to the vanilla Black-Scholes formulae as a proof-of-concept. I used ChatGPT to generate an initial piece of code, before tweaking it myself to improve the accuracy and configure the output how I wanted it. So this exercise is also an interesting demonstration of AI-assisted coding.

You can read the full article here

Below I’ve attached the python code that I used. The code trains the neural network using your Nvidia GPU if you have one, else it uses the CPU.

There’s many parameters you can alter, including the number of options to use in fitting, number and size of the layers in the neural network, and number of epochs to train for.

An interesting exercise would be to try to modify the code to work with more complex options, such as barrier options or American options.

Python Code

import numpy as np
import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import TensorDataset, DataLoader

# Black-Scholes formula for European call options
def bs_price(S, K, T, r, sigma):
    from torch.distributions import Normal
    sqrtT = torch.sqrt(T)
    d1 = (torch.log(S / K) + (r + 0.5 * sigma**2) * T) / (sigma * sqrtT)
    d2 = d1 - sigma * sqrtT
    norm = Normal(0., 1.)
    return S * norm.cdf(d1) - K * torch.exp(-r * T) * norm.cdf(d2)

# Generate dataset
N = 600_000
S = torch.rand(N, 1) * 100 + 1
K = torch.rand(N, 1) * 100 + 1
T = torch.rand(N, 1) * 2 + 0.01
r = torch.rand(N, 1) * 0.1
sigma = torch.rand(N, 1) * 0.5 + 0.01
prices = bs_price(S, K, T, r, sigma)

# Transform the data so S and T are one
K2 = K / S
T2 = torch.ones_like(K)
sigma2 = sigma * torch.sqrt(T)
DF = torch.exp(-r * T)
prices2 = prices / S

X = torch.cat([K2, T, r, sigma2, DF], dim=1)
y = prices2

train_size = int(0.8 * N)
X_train, X_test = X[:train_size], X[train_size:]
y_train, y_test = y[:train_size], y[train_size:]

batch_size = 512
dataset = TensorDataset(X_train, y_train)
loader = DataLoader(dataset, batch_size=batch_size, shuffle=True)

# Network configuration
hidden_size = 256
num_layers = 6

def build_model(input_dim, hidden_size, num_layers):
    layers = [nn.Linear(input_dim, hidden_size), nn.ReLU()]
    for _ in range(num_layers - 1):
        layers += [nn.Linear(hidden_size, hidden_size), nn.ReLU()]
    layers.append(nn.Linear(hidden_size, 1))
    return nn.Sequential(*layers)

class BSNet(nn.Module):
    def __init__(self):
        super(BSNet, self).__init__()
        self.model = build_model(5, hidden_size, num_layers)
    def forward(self, x):
        return self.model(x)

# Initialize
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
net = BSNet().to(device)
optimizer = optim.Adam(net.parameters(), lr=1e-3, weight_decay=1e-6)
criterion = nn.MSELoss()

# Training loop
epochs = 200
for epoch in range(1, epochs + 1):
    net.train()
    running_loss = 0.0
    for xb, yb in loader:
        xb, yb = xb.to(device), yb.to(device)
        preds = net(xb)
        loss = criterion(preds, yb)
        optimizer.zero_grad()
        loss.backward()
        optimizer.step()
        running_loss += loss.item() * xb.size(0)
    epoch_loss = running_loss / train_size
    if epoch % 50 == 0:
        print(f"Epoch {epoch}/{epochs}, Training MSE: {epoch_loss:.10f}")

def eval_test():
    net.eval()
    with torch.no_grad():
        X_device = X_test.to(device)
        preds = net(X_device)
        return criterion(preds, y_test.to(device)).item()

test_loss = eval_test()
print(f"\nTest MSE after {epochs} epochs: {test_loss:.10f}")

def price_option(S_val, K_val, T_val, r_val, sigma_val):
    net.eval()
    with torch.no_grad():
        valsbs = torch.tensor([[S_val, K_val, T_val, r_val, sigma_val]], device=device)
        vals = torch.tensor([[K_val/S_val, T_val, r_val, sigma_val*torch.sqrt(torch.tensor(T_val)), torch.exp(torch.tensor(-r_val*T_val))]], device=device)
        nn_p = net(vals).cpu().item()*S_val
        bs_p = bs_price(valsbs[:,0:1], valsbs[:,1:2], valsbs[:,2:3], valsbs[:,3:4], valsbs[:,4:5]).cpu().item()
    print(nn_p, bs_p)

print("\nTesting on some options:")
price_option(55, 60, 1.2, .03, .12)
price_option(340, 330, 1.4, .02, .15)
price_option(131, 131, 0.6, .02, .1)

Changes of Measure in Finance and why Forward Rate Agreements don’t Require a Convexity Adjustment.

Is measure theory really needed in finance?

Measure theory is an area of mathematics that was created to generalise the theory of integration to more exotic kinds of functions. It has applications in pure mathematics, particularly to the theory of differential equations – see, for example, Sobolev spaces. At some point, finance academics started using the language of measure theory when writing papers and textbooks about financial derivative pricing. However, the field of measure theory isn’t really necessary in finance because in almost all cases the functions that arise in derivative pricing in practice are nice, smooth functions that don’t require considerations from measure theory like sigma algebras. Couching derivative pricing in the language of measure theory simply makes it difficult for non-mathematicians to understand things which they would otherwise be able to understand.

The main concept from measure theory which is useful in derivative pricing is that of a “measure”. However, we only need a greatly simplified concept of it. In finance, a measure is basically just a smooth function which is used to weight or assign probabilities to different outcomes.

Futures convexity corrections

In this section, we discuss the convexity correction which accounts for the difference between forwards and futures prices. Later, we will identify another convexity correction that is required for late or early payment of interest (such as for swaps in arrears).

In this discussion, everything is with respect to the risk neutral measure, which takes into account investor’s risk preferences so that by definition expectations agree with market prices.

Consider modelling the short rate (instantaneous interest rate) \(r\) by a stochastic differential equation with time dependent drift \(\theta(t)\):

\[dr = \theta(t)dt + \sigma dz.\]

The forward rate \(F(t,T,T + \tau)\) between \(T\) and \(T+\tau\), as seen from time \(t\), is some function of the values of \(r(t)\) at each time \(t\). You’ll remember from calculus that when you want to find the rate of change of a function of a function, you use the chain rule, which generates an additional term. In Stochastic calculus, the chain rule is known as Ito’s Lemma, and it actually has three terms – it has an additional second order (or convexity) term that you don’t get in ordinary calculus. So, a function of a stochastic variable obeys its own stochastic differential equation which we can generate using Ito’s lemma. Because of the new third term, this new stochastic differential equation can have a drift term even if the original equation does not. In other words, even if \(\theta(t) = 0\), the forward rate equation can have a drift term, so that it’s expected value at time \(T\) is not the same as it’s value now at time \(t\). The precise equation for the expected future value is derived in this addendum to Hull.

We’ve seen that the forward rate is not a martingale under the risk neutral measure. In other words, it is not equal to its future expected value because the equation describing it has a drift term. By contrast, futures are martingales and are equal to their future expected values. The reason for this is simple. Because Futures are margined daily, their market value is by definition zero. So, since they cost nothing to buy, their expected future value, with respect to the risk neutral measure, must be zero as well. This means that the expected value tomorrow, or any future day, must be equal to today’s value.

This means that the equation derived in Hull for the expected future value of the forward, is also equal to the convexity correction between forwards and futures prices.

Change of numéraire

Changing the numéraire means changing the unit of measure used to value financial instruments. For example, changing to a different currency, or changing to the value of the same currency at some future time after it has appreciated due to the time value of money. We will refer to the wikipedia article on numeraires.

We consider the value of an asset \(S\) in terms of a numéraire \(M\). We assume the existence of a so-called risk neutral measure \(Q\) under which asset prices are martingales, that is the expected values at time \(T\) are the same as their current values:

\[\frac{S(t)}{M(t)} = E_Q \left[ \frac{S(T)}{M(T)} \right]\]

We define a new measure \(Q^N\) at time \(T\) by weighting all probabilities by the factor \(\frac{N(T)}{M(T)}\). Then we have the formula

\[E_{Q^N} \left[ \frac{S(T)}{N(T)} \right] = E_Q \left[\frac{N(T)}{M(T)} \frac{S(T)}{N(T)} \right] / E_Q \left[ \frac{N(T)}{M(T)} \right]\]

To understand this, note that when we switch back to calculating the expectation with respect to \(Q\), we have to add the weighting (or scaling) factor inside the expectation. In addition, because on the LHS everything is in terms of the numeraire \(N\), we have to have the division on the RHS so both sides are in the same numeraire (imagine a currency change). Note also that the expectation in the denominator is simply equal to the same expression evaluated at time \(t\), using the martingale property above.

The forward measure

Now we consider a particular example that we will need shortly. The time value of money means that a dollar today is worth more than a dollar in the future, leading to the use of discounting in pricing financial instruments. We let \(P(t,T)\) be the value at time \(t\) of a zero coupon bond which pays a cashflow of \(1\) at time \(T\) (effectively, this is the discount factor between \(t\) and \(T\)). Let’s choose a change of numeraire given by \(N(t) = P(t,T)\) and \(M(t) = P(t,T+\tau)\). Then we have

\[ \frac{N(t)}{M(t)} = \frac{1}{P(t,T,T+\tau)} = E_Q \left[ \frac{N(T)}{M(T)} \right], \]

where \(P(t,T,T+\tau)\) represents the forward rate as seen from time \(t\), and we have used the martingale property described above.

The new measure associated with this numeraire change is called the \(T + \tau\)-forward measure, and expectations with respect to this measure are denoted by \(E^{T + \tau}\).

Vanilla swap pricing and the forward measure

For a vanilla swap, the rate fixes at the start of each period, but the payment is settled at the end of each period.

Pricing a vanilla swap requires no complex modelling, as the valuation just involves computing the interest payments as if the future interest rates were equal to their current forward values. This is possible because the expected future value of the forward rate (with respect to the forward measure) is equal to its present value. In technical language, the forward rate is a “martingale”.

Consider a swap period starting at time \(T\) and ending at time \(T + \tau\), as seen from the current time \(t\). Let \(F(t,T,T + \tau)\) denote the forward interest rate over this period. The Martingale property means that

\[E^{T + \tau}\{F(T,T,T+\tau|\mathcal{F}_t\}=F(t,T,T+\tau).\]

The “filtration” \(\mathcal{F}_t\) simply indicates that the expectation is as seen from time \(t\), and we neglect it in what follows. The notation \(E^{T + \tau}\) means that the expectation is taken with respect to the (\(T + \tau\))-forward measure.

A clear explanation of this fact can be found in Brigo & Mecurio [1]. Rearranging the definition of a (simply compounded) forward rate slightly, we have

\[F(t,T,T + \tau)P(t,T + \tau) = \frac{1}{Y(T, T+\tau)}(P(t,T) – P(t,T+\tau)),\]

where \(Y\) represents the year fraction.

We now consider taking the expectation of both sides. Because of the discount factor on the LHS which scales all possible forward values by a constant factor, we are taking the expectation of the forward rate with respect to the (\(T + \tau\))-forward measure. On the other hand, the RHS is just the difference between the today-prices of two zero coupon bonds of different maturities. Since the latter are real assets trading in the market, their expected value must be equal to their current value. It follows that the same is true for the left hand side, i.e. the forward rate scaled by the discount factor.

Swap in arrears pricing

Swaps in arrears differ from vanilla swaps in that the both fixing and settlement occur at the start of each period. In this case, the expected future interest rate is no longer equal to the current forward value, necessitating a so-called convexity correction. The value of a swap in arrears is given by

\[V(t) = P(t,T) E^T \left[ F(t,T,T + \tau) \right].\]

For swaps in arrears, the expectation is taken at \(T\) instead of \(T + \tau\), so we can’t use the martingale property from the previous section. Using the change of numéraire formulae in a previous section, we can change to the (\(T + \tau\))-forward measure which introduces a discount factor inside the expectation as follows:

\[V(t) = P(t,T) E^{T+\tau} \left[ \frac{F(t,T,T + \tau)}{P(T,T+\tau)} \right] P(t,T,T+\tau)\]

\[= P(t,T+\tau) E^{T+\tau} \left[ \frac{F(t,T,T + \tau)}{P(T,T+\tau)} \right].\]

Because of the factor of \(1/P(T,T+\tau)\) inside the expectation, we can’t use the martingale property of forward rates here.

Attempting the quantify the magnitude of this correction is known as the “convexity correction”. It’s an amount that gets added to the forward rates before using them to price swaps, and calculating it requires that you first make a choice of stochastic interest rate model.

Why Forward Rate Agreements (FRAs) don’t require a convexity adjustment.

A FRA is similar to a single period swap, but not quite. A key difference is that the rate is fixed in advance, at the start of the accural period, just like a swap in arrears. However, unlike a swap in arrears, FRAs do not require a convexity adjustment, and one naturally wonders why. The answer lies in the second key difference between a FRA and a swap – for a FRA, the floating leg is discounted by the forward floating rate between the start and end dates of the accrual period. This discount factor, as seen from time \(t\), is

\[ P(t,T,T+\tau) = P(t,T+\tau)/P(t,T).\]

The value of a FRA is given by

\[V(t) = P(t,T) E^T \left[ F(t,T,T + \tau) P(T,T+\tau) \right],\]

which differs from a swap in arrears by the discount factor inside the expectation.

Note that if we now change to the (\(T + \tau\))-forward measure, as we did above for swaps in arrears, the new discount factor \(P(T,T+\tau)\) would exactly cancel with the change of measure \(1/P(T,T+\tau)\). Thus, FRAs don’t require a convexity correction.

Girsanov’s theorem

We’ve seen above how forwards are martingales under the forward measure, but have a drift term under the risk neutral measure. So it seems like one could get rid of a drift term by an appropriate measure, or conversely, change measure at the expense of adding a drift term. Girsanov’s theorem is the formalization of this idea.

[1] Brigo & Mecurio, Interest Rate Models – Theory and Practice, Springer Finance 2007