Posts | Joey O'Brien

Bootstrapping in the Open-Source Risk Engine

Wed, 15 Jul 2026 00:00:00 +0000

Open Source Risk Engine (ORE) is a powerful, production-grade risk analysis and pricing engine built on top of QuantLib. Having supported multiple clients through vendor replacement processes, we have seen first-hand that interest rate curve bootstrapping is always a critical first step. Reconciling a new open-source library against legacy vendor systems is an iterative, detailed task, and establishing a consistent curve bootstrap is the foundation upon which all downstream valuation and risk metrics depend.

Because ORE is entirely open-source, it offers unmatched transparency for quantitative finance professionals. Rather than dealing with a proprietary “black box”, developers and analysts can inspect every calculation, schedule rule, and day-count convention directly in the source code. A prime example of this transparency is ORE’s official CurveBuilding Examples on GitHub, which showcase how ORE constructs interest rate and inflation curves across different currencies and instruments.

In this post, we pull from these developer examples to walk through how to build a single USD Secured Overnight Financing Rate (SOFR) curve, which acts as both the discounting and forecasting index in the post-LIBOR USD market, and verify the consistency of the bootstrap by repricing the calibration instruments to zero present value (PV).

No C++ compilation is required. You can install the package and run the entire process in a few lines of Python:

pip install open-source-risk-engine matplotlib

1. Mapping the Model — `todaysmarket.xml`

To understand how ORE resolves your market data, it is helpful to look at the XML config dependency tree. The execution logic flows downward through this hierarchy, making the configuration mapping the natural starting point:

 ore.xml
│
└──> todaysmarket.xml
│
└──> curveconfig.xml
│
├──> conventions.xml
└──> market.txt

ore.xml: The master entry point that points ORE to the output directory, logs, portfolio file, and sub-configuration files.
todaysmarket.xml: The top-level mapping guide (detailed below). It tells ORE what curves we will build for this run, how to resolve them against configurations in curveconfig.xml, and what curves should be used for discounting and forwarding roles for each currency and index.
curveconfig.xml: Defines the recipe for building each individual curve (detailed in Section 4).
conventions.xml (detailed in Section 2) + market.txt (detailed in Section 3): Hold the underlying conventions details and numerical rate values.

For our single-curve USD SOFR build, todaysmarket.xml maps both the discounting curve and the index forwarding curve roles to the USD-SOFR curve identifier:

<TodaysMarket>
<Configuration id="default">
<DiscountingCurvesId>default</DiscountingCurvesId>
<IndexForwardingCurvesId>default</IndexForwardingCurvesId>
</Configuration>
<DiscountingCurves>
<DiscountingCurve currency="USD">USD-SOFR</DiscountingCurve>
</DiscountingCurves>
<IndexForwardingCurves>
<IndexForwardingCurve index="USD-SOFR">USD-SOFR</IndexForwardingCurve>
</IndexForwardingCurves>
</TodaysMarket>

This explicit mapping informs ORE that USD-SOFR is the reference curve for both discounting cashflows and projecting future daily SOFR coupon fixings.

2. Conventions — `conventions.xml`

Before feeding market quotes to the curve builder, ORE needs to know the financial conventions of the underlying instruments. Every swap coupon payment lag, day count fraction, and business day calendar mismatch will lead to pricing discrepancies if these details are not perfectly specified.

Indeed, a solid understanding of these conventions is key to successful interest rate modelling. For a comprehensive reference on global interest rate market conventions, see the guide by Marc P. A. Henrard: Interest Rate Instruments and Market Conventions Guide - Post LIBOR edition.

For the underlying mathematics of interest rate curve construction, interpolation methods, and multi-curve bootstrapping, the classic paper by Ferdinando M. Ametrano and Marco Bianchetti serves as the reference text: Everything You Always Wanted to Know About Multiple Interest Rate Curve Bootstrapping but Were Afraid to Ask. It is highly recommended reading if you want to dive deep into the bootstrapping mechanics.

For a standard USD SOFR curve build, we combine money market (MM) overnight deposit conventions for the short end and Overnight Indexed Swap (OIS) conventions for the longer tenors. Note, some practitioners would also use SOFR MM Futures as the second component of the bootstrap rather than going directly to OIS Swaps, this is entirely possible in ORE also. The conventions are defined in conventions.xml:

<Conventions>
<Deposit>
<Id>USD-ON-SOFR-DEPOSIT</Id>
<IndexBased>true</IndexBased>
<Index>USD-SOFR</Index>
</Deposit>
<OIS>
<Id>USD-SOFR-OIS</Id>
<SpotLag>0</SpotLag>
<Index>USD-SOFR</Index>
<FixedDayCounter>A360</FixedDayCounter>
<PaymentLag>2</PaymentLag>
<EOM>false</EOM>
<FixedFrequency>Annual</FixedFrequency>
<FixedConvention>MF</FixedConvention>
<FixedPaymentConvention>MF</FixedPaymentConvention>
<Rule>Backward</Rule>
</OIS>
</Conventions>

Deconstructing conventions

In ORE, curve conventions are mapped out with fine-grained parameters:

Overnight Deposit (USD-ON-SOFR-DEPOSIT): An index-based deposit linking directly to the USD-SOFR index.
OIS Conventions (USD-SOFR-OIS):
- <SpotLag>: Set to 0 days, meaning the swap starts immediately on the settlement date.
- <PaymentLag>: Set to 2 business days, meaning payments occur 2 days after the accrual period ends.
- <FixedDayCounter>: Set to A360 (Actual/360) day count basis.
- <FixedConvention> and <FixedPaymentConvention>: Set to MF (Modified Following business day rule).
- <Rule>: Set to Backward schedule generation.

3. Market Data — `market.txt`

Next, we define our market quotes. In a realistic curve build, we start the SOFR curve using the Overnight Money Market (MM) deposit rate helper at the very short end ($T+0$), followed by OIS swaps for the longer tenors. The data is provided in a simple space-delimited text format:

# Node Instrument Type Quote
2023-01-31 MM/RATE/USD/SOFR/0D/1D 0.0430000000
2023-01-31 IR_SWAP/RATE/USD/SOFR/0D/1D/1M 0.0456640000
2023-01-31 IR_SWAP/RATE/USD/SOFR/0D/1D/3M 0.0468210000
2023-01-31 IR_SWAP/RATE/USD/SOFR/0D/1D/6M 0.0483440000
2023-01-31 IR_SWAP/RATE/USD/SOFR/0D/1D/1Y 0.0487100000
2023-01-31 IR_SWAP/RATE/USD/SOFR/0D/1D/2Y 0.0427805000
2023-01-31 IR_SWAP/RATE/USD/SOFR/0D/1D/5Y 0.0346100000
2023-01-31 IR_SWAP/RATE/USD/SOFR/0D/1D/10Y 0.0324600000
2023-01-31 IR_SWAP/RATE/USD/SOFR/0D/1D/30Y 0.0300290000

Quote String Representation & Conventions Control

In ORE, market data quotes follow a structured string format that helps developers identify the instrument type, currency, index, and tenor:

MM/RATE/USD/SOFR/0D/1D: Represents a Money Market (MM) rate for the USD currency, tied to SOFR overnight (starting immediately, term of 1D).
IR_SWAP/RATE/USD/SOFR/0D/1D/30Y: Represents an Interest Rate Swap (IR_SWAP) rate for the USD currency, tied to SOFR overnight index with a tenor of 30Y.

Important: A common point of confusion when setting up ORE is assuming that ORE parses these quote strings to determine pricing behavior. This is not the case.

While the quote string contains parameters like the tenor (30Y) or settlement terms (0D/1D), the string serves strictly as a key identifier to match the market data row with the curve configuration. The actual financial behavior—such as compounding logic, schedule generation, payment lags, calendars, and rolling conventions—is driven entirely by the conventions defined in conventions.xml rather than parsed directly from the market data quote string itself.

4. Curve Configuration — `curveconfig.xml`

With conventions and quotes in hand, we assemble the curve recipe in curveconfig.xml. Because we are using two different types of instruments (a Deposit at the short end and Swaps for the rest of the curve), our configuration defines multiple <Simple> segments:

<CurveConfiguration>
<YieldCurves>
<YieldCurve>
<CurveId>USD-SOFR</CurveId>
<CurveDescription>USD SOFR OIS discount curve</CurveDescription>
<Currency>USD</Currency>
<DiscountCurve>USD-SOFR</DiscountCurve>
<Segments>
<Simple>
<Type>Deposit</Type>
<Quotes>
<Quote>MM/RATE/USD/SOFR/0D/1D</Quote>
</Quotes>
<Conventions>USD-ON-SOFR-DEPOSIT</Conventions>
<ProjectionCurve>USD-SOFR</ProjectionCurve>
</Simple>
<Simple>
<Type>OIS</Type>
<Quotes>
<Quote optional="true">IR_SWAP/RATE/USD/SOFR/0D/1D/1M</Quote>
<Quote optional="true">IR_SWAP/RATE/USD/SOFR/0D/1D/3M</Quote>
<Quote optional="true">IR_SWAP/RATE/USD/SOFR/0D/1D/6M</Quote>
<Quote optional="true">IR_SWAP/RATE/USD/SOFR/0D/1D/1Y</Quote>
<Quote optional="true">IR_SWAP/RATE/USD/SOFR/0D/1D/2Y</Quote>
<Quote optional="true">IR_SWAP/RATE/USD/SOFR/0D/1D/5Y</Quote>
<Quote optional="true">IR_SWAP/RATE/USD/SOFR/0D/1D/10Y</Quote>
<Quote optional="true">IR_SWAP/RATE/USD/SOFR/0D/1D/30Y</Quote>
</Quotes>
<Conventions>USD-SOFR-OIS</Conventions>
</Simple>
</Segments>
<InterpolationVariable>Discount</InterpolationVariable>
<InterpolationMethod>LogLinear</InterpolationMethod>
<YieldCurveDayCounter>A365</YieldCurveDayCounter>
<Tolerance>0.0000000000010000</Tolerance>
<Extrapolation>true</Extrapolation>
</YieldCurve>
</YieldCurves>
</CurveConfiguration>

Unmatched Control Over Curve Building

One of ORE’s core strengths is the level of mathematical control it gives you over the curve construction process. Rather than restricting you to a single hard-coded solver, ORE exposes configuration fields for every stage of the interpolation and bootstrapping math:

A. Interpolation Variables

You can choose the domain on which interpolation is performed (<InterpolationVariable>):

Discount (Default): Interpolates discount factors directly.
Zero: Interpolates continuously compounded zero rates.
Forward: Interpolates instantaneous forward rates.

B. Interpolation Methods

ORE supports a wide variety of interpolation algorithms (<InterpolationMethod>), letting you select the method that best aligns with your risk and pricing needs:

Linear / LogLinear: Simple and robust. LogLinear interpolation on Discount factors is equivalent to assuming piecewise-constant forward rates (flat forwards)—a standard market choice.
NaturalCubic / FinancialCubic: Smoother cubic spline variants. FinancialCubic ensures zero second derivative at the left edge and zero first derivative at the right edge.
ConvexMonotone: Hagan & West’s method, designed to preserve convexity and monotonicity of forward rates.
LogNaturalCubic / LogFinancialCubic / LogCubicSpline: Cubic splines applied in the natural log domain of the target variable.
BackwardFlat: Piecewise constant, right-continuous interpolation.

C. Handling the $t_0$ Reference Date

The optional <ExcludeT0FromInterpolation> element (set to True or False) lets you exclude the synthetic time-zero ($t_0$) reference point (where $DF=1.0$) from the interpolation grid. When set to True, the curve interpolates strictly on actual market pillar dates, using flat zero/forward rates between $t_0$ and the first pillar. This avoids forcing a synthetic anchor point that can distort the short end of the curve.

D. Bootstrapping Precision & Performance

Under the optional <BootstrapConfig> node, ORE exposes parameters for the iterative root-finding procedure:

<Accuracy> (Default: 1e-12): The desired tolerance for the root-finding solver to match market quotes.
<GlobalAccuracy>: Tolerable fallback accuracy if target accuracy cannot be met.
<DontThrow>: If set to True, ORE will continue execution using the best fit found rather than throwing an exception if the global accuracy check fails.
<MaxAttempts> (Default: 5): Maximum attempts/seed trials for fitting complex curves (like Fitted Bond curves using Nelson-Siegel or Svensson methods).
<ExtrapolationMethod>: Controls curve tails using ContinuousForward (flat instantaneous forwards) or DiscreteForward (flat daily forwards).

5. Bootstrapping and Plotting in Python

We can execute the entire calibration run and extract the zero rates directly in a Python script. ORE reads our master execution config (ore.xml) and calibrates the curve.

Here is the Python script to run the bootstrapping and plot the zero curve:

import os
import ORE as ore
import csv
import matplotlib.pyplot as plt
from pathlib import Path
# Set up base path relative to this script
BASE_DIR = Path(__file__).parent.resolve()
INPUT_DIR = BASE_DIR / "Input"
OUTPUT_DIR = BASE_DIR / "Output"
os.makedirs(OUTPUT_DIR, exist_ok=True)
# 1. Run the ORE App
params = ore.Parameters()
params.fromFile(str(INPUT_DIR / "ore.xml"))
app = ore.OREApp(params)
app.run()
print("\n--- ORE Run Completed Successfully ---\n")
# 2. Extract bootstrapped curve rates
analytic = app.getAnalytic("NPV")
market = analytic.getMarket()
curve = market.discountCurve("USD")
tenors = {
"1M": 1/12,
"3M": 0.25,
"6M": 0.5,
"1Y": 1.0,
"2Y": 2.0,
"5Y": 5.0,
"10Y": 10.0,
"30Y": 30.0
}
times = []
zero_rates = []
print("Discount Factors and Zero Rates (as of 2023-01-31):")
print(f"{'Tenor':<8} {'Time (y)':<10} {'Discount Factor':<18} {'Zero Rate (%)':<15}")
print("-" * 55)
for name, t in tenors.items():
df = curve.discount(t)
zero = curve.zeroRate(t, ore.Compounded, ore.Annual).rate()
times.append(t)
zero_rates.append(zero * 100)
print(f"{name:<8} {t:<10.4f} {df:<18.8f} {zero*100:<15.4f}%")
# 3. Plot the zero curve
fig, ax = plt.subplots(figsize=(10, 5))
ax.plot(times, zero_rates, marker="o", linewidth=2, color="steelblue", label="USD SOFR Zero Rate")
ax.set_xlabel("Time (years)")
ax.set_ylabel("Zero Rate (%)")
ax.set_title("Bootstrapped USD SOFR Zero Curve (As of 2023-01-31)")
ax.legend()
ax.grid(True, linestyle="--", alpha=0.5)
plt.tight_layout()
plt.savefig("zero_curve.png", dpi=150)
plt.show()
print("Zero curve saved to zero_curve.png")

When we run this script, we obtain the zero-rate curve plot shown below:

Bootstrapped USD SOFR Zero Curve (As of 2023-01-31)

6. Under the Hood: ORE Calibration Reports

One of the most powerful features added in recent ORE releases is the automatic generation of detailed calibration reports. In the execution output, you will find todaysmarketcalibration.csv and todaysmarketcalibration_cashflows.csv under the Output directory.

For anyone trying to understand the mechanics of the bootstrap, todaysmarketcalibration_cashflows.csv is an absolute goldmine.

Instead of treating the bootstrap as a black-box mathematical solver, ORE writes out the complete cashflow schedule of every rate helper instrument utilized in the curve calibration. For each instrument (e.g., our USD SOFR OIS swaps), the report details:

Pillar Dates and Accrual Start/End Dates.
Projected Interest Amounts and Accrual Fractions.
Fixing Dates and Forward Rate Fixing Values.
Discount Factors and Present Values (PV) of both legs.

Having direct visibility into these details significantly speeds up the implementation and debugging process. Day-count fraction errors or payment lag mismatches become instantly noticeable as you inspect the exact schedules and discount factors used.

To see this in action, here is an extract of the cashflows for the 2Y OIS Swap (market fixed quote: 4.27805%) from the report. It shows how the Fixed and Floating legs are structured:

Leg	Pay Date	Accrual Start	Accrual End	Accrual Fraction	Rate (%)	Discount Factor	Present Value (USD)
Fixed	2024-02-02	2023-01-31	2024-01-31	1.013889	4.27805%	0.952687	41,322.50
Fixed	2025-02-04	2024-01-31	2025-01-31	1.016667	4.27805%	0.918343	39,941.96
Floating ¹	2024-02-02	2023-01-31	2024-01-31	1.013889	4.87100%	0.952687	-47,049.92
Floating ¹	2025-02-04	2024-01-31	2025-01-31	1.016667	3.66461%	0.918343	-34,214.54

¹ On an OIS floating leg, no single overnight rate is fixed in advance. Instead, the daily SOFR fixings are compounded over each accrual period. The rates shown above (4.87100% for Period 1 and 3.66461% for Period 2) are the equivalent flat rate that would produce the same compounded interest amount over the period—sometimes called the projected par coupon rate. Period 1’s rate exactly matches the 1Y market quote (4.871%), which makes sense: the 1Y OIS calibration instrument was already bootstrapped, and its projected compounded rate is the 1Y fair rate. Period 2’s rate (3.665%) is what the bootstrapper must solve for to make the 2Y swap price at par.

Summing the present values:

Fixed Leg PV: $+81,264.46$ USD
Floating Leg PV: $-81,264.46$ USD
Net Swap NPV: $0.00$ USD

This demonstrates the mathematical core of the bootstrap: the solver finds the equivalent compounded forward rate for the second period (3.66461%) such that the floating leg PV exactly matches the fixed leg PV.

7. From Conventions to Dates — A Worked Example

The cashflow report above is where we can see the exact output of ORE’s date math. Rather than being magic numbers, every single date and accrual fraction here is a direct, deterministic consequence of the as-of date, the instrument tenor, and the conventions.

For our 2Y USD SOFR swap, ORE picks up the conventions from the <Conventions>USD-SOFR-OIS</Conventions> node in curveconfig.xml. This refers back to the matching <OIS> convention block in conventions.xml containing SpotLag, PaymentLag, FixedDayCounter, Rule, etc.

Here is how ORE resolves the dates step-by-step for the 2Y instrument:

Step 1 — Determine the Start Date (`SpotLag = 0`)

Our market data as-of date is 2023-01-31. Since <SpotLag> is set to 0, there is no settlement delay. The swap starts immediately on the trade date:

$$\text{Start Date} = \text{2023-01-31} + 0 \ \text{business days} = \textbf{2023-01-31}$$

Step 2 — Determine the End Date (Tenor = 2Y)

Adding the 2Y tenor to our start date gives the unadjusted end date:

$$\text{Unadjusted End} = \text{2023-01-31} + 2Y = \text{2025-01-31}$$

Since January 31, 2025 is a Friday (a valid business day), no business day adjustment is needed. The maturity date is 2025-01-31.

Step 3 — Generate the Schedule (`Rule = Backward`)

Because the schedule rule is set to Backward, ORE builds the schedule by stepping back from the maturity date in annual increments (based on <FixedFrequency>Annual</FixedFrequency>):

Step	Date	Adjustment	Result
Maturity	2025-01-31	—	2025-01-31
−1Y	2024-01-31	Valid business day	2024-01-31
−2Y	2023-01-31	Valid business day (= Start)	2023-01-31

This gives us two accrual periods:

Period 1: 2023-01-31 to 2024-01-31
Period 2: 2024-01-31 to 2025-01-31

Step 4 — Calculate Payment Dates (`PaymentLag = 2`)

Payments are made 2 business days after the end of each accrual period, adjusted using the Modified Following (MF) business day convention:

Accrual End	+2 bd	Payment Date
2024-01-31 (Wed)	→ 2024-02-01 (Thu) → 2024-02-02 (Fri)	2024-02-02 ✓
2025-01-31 (Fri)	→ 2025-02-03 (Mon) → 2025-02-04 (Tue)	2025-02-04 ✓

These dates match the PayDate values in our cashflow report exactly.

Step 5 — Calculate Accrual Fractions (`FixedDayCounter = A360`)

Using the Actual/360 convention, we divide the actual number of calendar days in the period by 360:

Period	Start	End	Actual Days	Fraction (days/360)
1	2023-01-31	2024-01-31	365	$365 / 360 = \mathbf{1.013889}$ ✓
2	2024-01-31	2025-01-31	366	$366 / 360 = \mathbf{1.016667}$ ✓

Note that 2024 is a leap year, so the second period contains 366 calendar days, yielding the slightly larger accrual fraction seen in the report.

Step 6 — Calculate the Fixed Coupon Amount

With a fixed rate of 4.27805% and a $1,000,000 notional, the coupon for the first period is:

$$\text{Coupon}_1 = 1{,}000{,}000 \times 0.0427805 \times 1.013889 = \mathbf{$43{,}374.67}\text{ USD}$$

Discounting this cashflow with the bootstrapped 1Y discount factor of 0.952687 gives:

$$\text{PV}_1 = 43{,}374.67 \times 0.952687 = \mathbf{$41{,}322.50}\text{ USD}$$

Both figures reconcile perfectly with the values in the ORE calibration report. Everything falls out cleanly from just a few parameters: the start date, the tenor, spot lag, frequency, payment lag, and day count convention.

8. Verification — The Zero-PV Repricing Check

A successful bootstrap means that the constructed curve must perfectly replicate the market prices of the instruments used to build it. To prove this, we construct a portfolio of matching OIS swaps in portfolio.xml (e.g., matching the 1M, 1Y, and 5Y points with the respective market fixed rates) and price them against our newly constructed curve:

<Portfolio>
<Trade id="OIS_5Y">
<TradeType>Swap</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<SwapData>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
<Currency>USD</Currency>
<Notionals><Notional>10000000</Notional></Notionals>
<DayCounter>A360</DayCounter>
<PaymentConvention>ModifiedFollowing</PaymentConvention>
<PaymentLag>2</PaymentLag>
<FixedLegData><Rates><Rate>0.034610</Rate></Rates></FixedLegData>
<ScheduleData>
<Rules>
<StartDate>2023-01-31</StartDate>
<EndDate>2028-01-31</EndDate>
<Tenor>1Y</Tenor>
<Calendar>US</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Backward</Rule>
</Rules>
</ScheduleData>
</LegData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
<Currency>USD</Currency>
<Notionals><Notional>10000000</Notional></Notionals>
<DayCounter>A360</DayCounter>
<PaymentLag>2</PaymentLag>
<PaymentConvention>ModifiedFollowing</PaymentConvention>
<FloatingLegData>
<Index>USD-SOFR</Index>
</FloatingLegData>
<ScheduleData>
<Rules>
<StartDate>2023-01-31</StartDate>
<EndDate>2028-01-31</EndDate>
<Tenor>1Y</Tenor>
<Calendar>US</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Backward</Rule>
</Rules>
</ScheduleData>
</LegData>
</SwapData>
</Trade>
</Portfolio>

When ORE prices these trades using the bootstrapped curve, the output reports NPVs of exactly 0.000000:

Trade ID	Leg 1 Type	Leg 2 Type	Notional (USD)
OIS_1M	Fixed	Floating	10,000,000.00
OIS_1Y	Fixed	Floating	10,000,000.00
OIS_5Y	Fixed	Floating	10,000,000.00

This confirms that our bootstrapping configuration is consistent and perfectly reproduces the input market quotes.

9. Sanity Check — Breaking the Linkage

To demonstrate that our zero-PV result is a meaningful validation of the bootstrap rather than a configuration triviality, we can introduce a deliberate mismatch. If we perturb one of the swap fixed rates in our portfolio to 3.561% (+10 bps) without rebuilding the curve, and re-price:

Trade ID	NPV (USD)	Base NPV (USD)
OIS_5Y	45,379.995138	45,379.995138

The NPV deviates significantly from zero. This demonstrates that the zero-PV check is highly sensitive to the exact alignment between the curve calibration quotes and the trade valuation models.

10. Testing ORE Against Your Existing System

If you are looking to integrate ORE into your workflow, the best way to start is by testing it against your current library or legacy pricing system. This is typically an iterative process:

Align on Conventions & Market Data: Ensure your day-count conventions, calendar adjustment rules, holiday calendars, spot lags, and market rate inputs (in market.txt) are exactly identical to your current system.
Replicate the Curve Configuration: Re-create the interpolation method (e.g., LogLinear discount factor interpolation) and segment definitions.
Compare Discount Factors: Calibrate the curves in both systems for the same as-of date and compare the resulting discount factors at various tenors.

Discrepancies during this comparison are common and usually trace back to subtle differences in schedule rules or accrual fraction calculations. This is where ORE’s new todaysmarketcalibration_cashflows.csv report becomes invaluable. By comparing ORE’s detailed cashflow schedule and discount factors side-by-side with vendor libraries, you can pinpoint the exact payment date or compounding difference causing the divergence, drastically reducing integration time.

By following this disciplined comparison, you can gain high confidence in ORE’s open-source calculations. But establishing a solid, verified bootstrap is just the first step. Once you have matching curves, you unlock the ability to leverage ORE’s wider ecosystem for full portfolio valuation, XVA, historical simulation, and market risk analytics. Reconciling your curves is the ideal foundation for a much broader ORE integration journey.

Source Code

All configuration files and the Python script used in this post are available for download here.

Disclaimer: The minimal ORE inputs utilized in this post, along with the featured graphics, were generated and coordinated using Gemini 3.5 Flash and Nano Banana 2.

Speaking at LSEG Quant Summit London 2026

Tue, 12 May 2026 00:00:00 +0000

On May 11, 2026, I spoke at the LSEG Quant Summit London 2026 held in Paternoster Square, London. The event focused on the latest developments in the Open-Source Risk Engine (ORE) ecosystem.

I presented on two key areas during the summit:

ORE in the Era of Agentic AI This presentation explored how Large Language Models (LLMs) and AI agents are transforming quantitative finance. Key topics covered included:
- The capabilities and limitations of modern LLMs in writing pricing and risk models.
- Real-world use cases of AI agents automating workflows and creating value within the ORE framework.
- The integration of the Model Context Protocol (MCP) to connect AI agents directly with specialized quantitative tools.
- LSEG’s collaborative efforts in this space, including partnerships with leading AI labs like Anthropic.
LSEG’s Internal Adoption of ORE This talk discussed LSEG’s internal adoption, integration, and scaling of the Open-Source Risk Engine (ORE) across its post-trade services and risk management infrastructure, showcasing the practical value of open-source analytics at scale.

It was fantastic to connect with other quantitative researchers, developers, and risk professionals to discuss the future of open-source risk analytics, enterprise integration, and artificial intelligence.

For more information about the summit, you can visit the LSEG Quant Summit London 2026 event page.

Building a tidy data pipeline: Covid19 Northern Ireland

Sun, 30 Jan 2022 00:00:00 +0000

One of the many scientific benefits that have occurred since the start of the Coronavirus pandemic is the emergence of large-scale open access data describing the dynamics of the virus at a range of scales. Governments, health organizations, and many others have produced data at a unparalleled rate to help society understand how the disease has rampaged through society.

Of course the quality of production of this data varies greatly depending on the producer. Ideally for those interested in data analytics/science the data would be readily available in a clean and tidy format which allows quick analysis to be done. Such ideas are generally considered by data engineers (which I, unfortunately, wouldn’t count myself as) to produce pipelines to collect, clean, and update the data on a regular basis to keep up with the latest figures.

Motivated by this, I have produced a framework to consider such data describing the pandemic in the case of Northern Ireland. The Department of Health NI produce a fantastic summary of the main metrics describing the disease including, cases, testing, hospitilizations, and deaths arising from Covid-19 on a daily-ish basis (more on this in a moment). Unfortunately, for those of us who want to access data as quickly and cleanly as possible, the data is stored in rather clunky .xlsx spreadsheets with each tab representing a different summary.

So the aim of this post is to describe how one can produce a pipeline to

Look for the latest spreadsheet on a daily basis.
Extract the needed info from each of the sheets of the .xlsx file individually.
Clean this data in a more usable format.
store the data in a public repository for others to use.

This is exactly the framework introduced in the covid19northernireland repo hosted on my github. Let me now talk you through the main workings of the software and how the individual codes work.

First let’s load the required packages in R.

library(tidyverse) # for data wrangling
library(janitor) # for cleaning dataframes
library(padr) # dealing with missing values
library(zoo) # time series handling
library(readxl) # reading xlsx workbooks
library(httr) # for storing downloaded files temporarily

First of all, the spreadsheets are stored at a URL with the following form:

https://www.health-ni.gov.uk/sites/default/files/publications/health/doh-dd-19-november-2021.xlsx

so we will need to provide the current date to build the URL, however the files are also only updated on weekdays so we can use a little function to correct for that and then save the file lcoally for analysis as follows

most_recent_weekday <- function(date){
# function to take a date input and return the most recent weekday
if(weekdays(date) == "Saturday"){
return(date - 1)
}else if(weekdays(date) == "Sunday"){
return(date - 2)
}else{
return(date)
}
}
data_date = format(most_recent_weekday(Sys.Date()), "%d%m%y")
fname = paste0('https://www.health-ni.gov.uk/sites/default/files/publications/health/doh-dd-', data_date,'.xlsx')
# download the file and store a connection to it in xls_file
httr::GET(fname, write_disk(xls_file <- tempfile(fileext = ".xlsx")))

## Response [https://www.health-ni.gov.uk/sites/default/files/publications/health/doh-dd-280122.xlsx]
## Date: 2022-01-30 21:33
## Status: 200
## Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
## Size: 3.14 MB
## <ON DISK> C:\Users\JOEYOB~1\AppData\Local\Temp\Rtmp2V42oQ\file4a6871c01034.xlsx

Now we have a connection to the latest version of the spreadsheet stored in the variable xls_file (thanks to the httr package). Generally we use .csv files when interacting with smaller tabular files, however in this case it is actually an xlsx file and such it has sheets. Fortunately the readxl packages allows us to read directly from a given sheet by providing its name (we’ll look at the Summary Tests sheet) as follows

test_df <- read_excel(xls_file, sheet = "Summary Tests")
test_df

## # A tibble: 730 x 7
## Sample_Date `TOTAL TESTS` `INDIVIDUALS TESTED PO~ `ALL INDIVIDUALS T~
## <dttm> <dbl> <dbl> <dbl>
## 1 2020-01-05 00:00:00 3 0 0
## 2 2020-01-07 00:00:00 1 0 0
## 3 2020-01-11 00:00:00 1 0 0
## 4 2020-01-16 00:00:00 2 0 0
## 5 2020-01-18 00:00:00 2 0 0
## 6 2020-01-21 00:00:00 1 0 0
## 7 2020-01-22 00:00:00 1 0 0
## 8 2020-01-25 00:00:00 1 0 0
## 9 2020-01-27 00:00:00 1 0 0
## 10 2020-01-31 00:00:00 1 0 0
## # ... with 720 more rows, and 3 more variables:
## # ROLLING 7 DAY POSITIVE TESTS <dbl>, ROLLING 7 DAY INDIVIDUALS TESTED <dbl>,
## # POSITIVITY RATE PER 100K POP <dbl>

Now if we take a look through this data we will note that its hygiene (no offence…) isn’t the best. First of all the column names have spaces, and there is nothing a data scientist dislikes more than spaces in variable names (perhaps a slight exaggeration but then again maybe not). As such the first thing we will do is use the janitor::clean_names() function which is fantastic at repairing these troublesome naming conventions. Second we don’t want all the columns in this instance so we can use dplyr::select() to take what we need. Furthermore, if we check the data we note that the date column Sample_Date isn’t consistent in that some days aren’t present this is quickly fixed with the padr::pad() function that, as the name suggests, pads the missing days. Lastly, there are some columns where those days with no values (cases, deaths,…) are represented by NA which we don’t really want to be the case as there is information in these values so that can be resolved using tools from dplyr also. All together we have went through a whirlwind step of data cleaning to have a much tidier and user-friendly data frame as seen below

test_df %>%
clean_names() %>%
select(date = sample_date,
cases = individuals_tested_positive,
tests = all_individuals_tested,
cases_per_100k = positivity_rate_per_100k_pop
) %>%
pad('day') %>%
mutate_if(is.numeric, funs(ifelse(is.na(.), 0, .))) %>%
filter(date >= '2020-03-05')

## # A tibble: 694 x 4
## date cases tests cases_per_100k
## <dttm> <dbl> <dbl> <dbl>
## 1 2020-03-05 00:00:00 2 18 0.106
## 2 2020-03-06 00:00:00 2 14 0.106
## 3 2020-03-07 00:00:00 5 14 0.264
## 4 2020-03-08 00:00:00 3 18 0.158
## 5 2020-03-09 00:00:00 3 35 0.158
## 6 2020-03-10 00:00:00 5 92 0.264
## 7 2020-03-11 00:00:00 11 91 0.581
## 8 2020-03-12 00:00:00 4 72 0.211
## 9 2020-03-13 00:00:00 11 78 0.581
## 10 2020-03-14 00:00:00 10 62 0.528
## # ... with 684 more rows

Now there is so much more data in the file that we can pull but this would turn into a rather long post if I continued describing every one of the steps but please do check out the entire code here if interested.

The main point however is that from this collection + cleaning exercise we create four separate tidy .csv files (found here) which are much easier to analyse in a data science setting.

Of course we want these files to continually update each time the corresponding spreadsheet is updated. And no, I do not want to remember to run the script each day. Therefore the best option is to set up some pipeline that will run the script automatically on a virtual machine each day. This is done using a .yaml script that runs my script from the cloud each night at 10pm before committing the files in the aforementioned repository for use by others. The format of this script looks like this:

name: covid_northernireland_data_update
# Controls when the action will run.
on:
schedule:
- cron: '00 22 * * *'
jobs:
CovidDataScrape:
# The type of runner that the job will run on
runs-on: windows-latest
# Load repo and install R
steps:
- uses: actions/checkout@master
- uses: r-lib/actions/setup-r@master
# Set-up R
- name: Install Packages
run: |
install.packages('tidyverse')
install.packages('janitor')
install.packages('padr')
install.packages('zoo')
install.packages('readxl')
install.packages('httr')
shell: Rscript {0}
# Run R script
- name: Get Data
run: Rscript code/01_data_update.R
# Add new files in data folder, commit along with other modified files, push
- name: Commit Files
run: |
git config --local user.name 'obrienjoey'
git config --local user.email "mr.joeyob@gmail.com"
git add data/*
git commit -am "update NI Covid19 data $(date)"
git push origin main
env:
REPO_KEY: ${{secrets.GITHUB_TOKEN}}
username: obrienjoey

So there we have it, a fully fledged workflow to collect, clean, and store the required data in a systematic and tidy manner. I hope this discussion can be useful for you in creating your own data pipelines (and make us all appreciate the godly work of data engineers more!) allowing for clean and automatic data collection for whatever project comes your way!

A complex networks approach to ranking professional Snooker players

Mon, 03 May 2021 00:00:00 +0000

One does not have to look far to observe the innate desire us humans have to rank things. Each year we are faced with endless awards ceremonies—just think about the Oscars, Grammys, Ballon d’Or, Time Person of the Year… the list goes on and on. Indeed, at the turn of every year/decade/century media organizations fill whitespace with their “top 100 (insert domain of interest here) of (insert temporal period here)” where a supposed expert gives their thoughts on the optimal ordering of entities from the domain of choice. These rankings are, however, far from definitive, and rather than settle an argument they instead tend to simply add fuel to the fire of the debate. The main problem with these approaches is that the rankings tend to be based upon personal preference with an extremely high level of subjectivity (the player who scored the goal that won their team the cup, the movie they saw on their first date…). In an ideal science-based world, however, any ranking would be determined using an entirely objective approach which, unfortunately, requires detailed data describing the interactions between different entities to determine who/what exactly is the best.
While the collection of such data can prove difficult for most domains, one area in which there is no shortage of detailed historical data of competition is within the field of sport. Rather, there is in fact a data revolution taking place in sport whereby athletes are becoming increasingly aware of statistics and, moreover, devoted fans of said sports have amassed huge collections of historical results that readily allow for data-driven mathematical analysis to be conducted. Motivated by this, researchers at MACSI (Mathematics Applications Consortium for Science and Industry) based in the University of Limerick in Ireland posed the following problem—who is the greatest snooker player of all time? For the unaware, snooker is a cue-based game in which competitors compete head-to-head by trying to strike balls on a rectangular table and obtain points, based upon the denomination of the ball, as a result of successfully landing it within one of the six “pockets” or holes on the table. Like most sports, there is constant discussion regarding which competitor is the greatest to have graced the game. To answer the question in a quantitative manner the first thing needed was detailed data of results from the sport which were obtained via a large data scraping exercise (involving pulling statistics from multiple webpages). This resulted in a collection of the match results from over fifty years (1968-2020), amounting to 657 tournaments featuring 1,221 unique players competing in 47,710 matches. With this data at hand, the question then becomes how best to use it in ranking the competitors. Perhaps the most obvious thing to do would be simply to count the number of times each player had won, the equivalent of giving the Oscar to the highest grossing movie—not ideal. The issue with this approach is in the fact that the player with the most wins could simply repeatedly play Joe Bloggs at the snooker hall. In order to offer an alternative approach, we make use of the network description of this data. This network is obtained by letting each player be represented by a node and for each match an edge is drawn from the losing node to the corresponding winning node.

(a) Probability distribution of the number of matches (blue), wins (pink), and losses (green) for each professional Snooker player. Each point shows the fraction of players that had a certain number of each quantity. Note the scale of both axes are logarithmic suggesting that most players appear in very few matches while a select few appear much more often. (b) Corresponding plot but now showing the probability of having more than a certain number of matches for each player.

Figure 1 shows the corresponding probability distributions describing the number of matches, wins, and losses for each player, which appears to be highly skewed, suggesting a form of “Matthew effect” occurring in the sport in that a select few players win many games while many players win very few. Using this networked representation, an algorithm was proposed which could be used in identifying a ranking of the most important players. In particular, this algorithm considers not only how many times one player defeated another but also how frequently the defeated player themselves defeated others. In this sense each player has some associated prestige describing their quality, and in defeating a player the winner receives some of this associated prestige. This implies that a win against a strong competitor with high prestige is now more worthwhile to a player’s rank than defeating a weaker competitor.

Using the approach described above, after constructing a network based upon all recorded professional snooker games, it can quickly be determined who is the greatest player of all time. Interestingly, it is not Ronnie O’Sullivan with his natural talent, Steve Davis and his distinguished trophy room, or the winning machine known as Stephen Hendry, but rather the four-time world champion John Higgins! This result may seem surprising to some snooker fans but when the data is considered it is entirely understandable. While both Davis and Hendry have plenty of trophies and wins to their name, the quality of player competing in their era was considerably less than those faced by Higgins and O’Sullivan (who is ranked the second greatest through our approach).

Rankings of the top 30 Snooker players of all time based upon the level of prestige determined via the proposed algorithm (vertical axis) compared to their ranking based upon total wins (horizontal axis). The red line acts as a reference for those players who were ranked higher by prestige than wins (under the line) and vice-versa (above the line).

Moreover, this approach can give an indication as to which players have faced tougher competition in wins during their careers. This is highlighted in Figure 2 where the top 30 players ranked using the prestige approach (our algorithm) is compared to their ranking based upon the number of wins. While the two ranking schemes are clearly very correlated, a considerable amount of information may be obtained from the location of players within this graphic. Those players who are above the red line (Davis, Hendry, White…) have obtained their wins from less competitive games (i.e., their wins were accumulated against players with less prestige), while the contrary is true for those below the line, many of whom are from the modern era. In order to help satisfy the intrinsic human desire to rank entities, this work has proposed a method which utilizes a mathematical framework to determine a ranking of competitors which considers not only the number of times a player has won but also the quality associated with each win. Excitingly, this concept offers plenty of room for extension to any domain for which detailed data on interactions is available and can hopefully help in ending the many arguments about the greatest competitor in your favourite area of interest!

This article originally appeared on Oxford University Press Blog, the article can be found here.

Covid-19 and the Irish Routine

Mon, 01 Jun 2020 00:00:00 +0000

The way in which the terrible virus that is Covid-19 has rampaged through the entire world over the course of 2020 has altered the behaviour of humanity in a way no one could have foreseen. With the aim of understanding the properties of this disease alongside the way in which it is (and ultimately will) spread through and affect society has resulted in a momentous collaborative effort across all areas of science from epidemiologists all the way through to economists. The community of applied mathematicians and statisticians have been conducting research at the forefront of this effort through developing compartmental models not unlike those seen in an introductory dynamical systems course and making use of a variety of datasets in order to both increase the complexity of the models and also infer the parameters needed to fit said models with the empirical incidence rate.

The requirement for datasets to aid this scientific endeavour and inform society itself has resulted in large companies making some of their (usually vaulted!) data – generated through the digital traces left every day when interacting with technology – publicly available. Arguably the most obvious demonstration of this is the mobility data provided by two of the world’s largest corporations – Apple and Google. Both of whom are currently providing aggregated data from requests made to their corresponding map services over multiple geographical resolutions ranging from country, to county, to in some cases city levels. This offers the potential to gain an insight into just how much the daily Irish routine has been altered in the age of social distancing and travel restrictions. To demonstrate some of these insights two data sources in the case of Ireland are considered below.

Apple

Apple have released daily country level time series data on how levels for three modes of transport – driving, walking, and public transport – changed relative to the baseline values from January 13th. One may see in the early points of the time series in Figure 1 that Irish society had a relatively consistent weekly pattern of all three modes of transport with two consecutive peaks (the weekends) followed by five more modest values describing the weekdays. The first reported case of the virus on Irish shores occurred on the 29th February but we see that it is almost two full weeks before a significant change in the transport levels occur when the Containment Phase strategy was introduced with the closure of schools and colleges on March 12th.

Apple Mobility Data

The readily increasing number of cases resulted in the announcement of national travel restrictions on March 27th and on this date arguably the most interesting point in the entire time series is seen with a significant increase suggesting a possible `last chance saloon’ to travel home before restrictions came into place. One may then observe over the following two months how the country was brought to a near standstill in terms of mobility. Also, interestingly, it can be seen that Apple had missing data from the 10th and 11th of May showing how even the largest corporations can run into problems with data collection! Restrictions began to ease through the end of May as the number of cases had slowed and a roadmap of Phases were proposed with specific relaxations at each point. After Phase 1 (18th May), which involved increasing the permitted travel distance to 5km from one’s home, an increase in mobility across all modes occurs and further gains after the commencement of Phase 2 which further extended the travel distance to 20km. The levels of mobility is gradually returning to those seen prior to the start of Covid-19 as the growth in the number of cases decreases.

Google

Similar to Apple, Google has also released aggregated time series of requests to their own map service but with a different set of descriptions. Rather than the mode of transport used above, Google released requests regarding six distinct categories – retail and recreation, grocery and pharmacy, parks, transit stations, workplaces, and residential areas. They also provided a finer level of resolution namely at a county level. Here two of the categories (residential and workplaces) at six different Thursdays over the past few months are considered.

Google Workplace Data

The set of plots in Figure 2 shows the percentage change in the frequency at which people were at a workplace from a baseline taken over January 3rd – February 6th. A considerable decrease as the restrictions were at their strongest up to the end of April is seen. In the final two maps however a return to normality is observed as the restrictions have lifted demonstrating people returning to work. One interesting aspect throughout is the level of workplace activity in Dublin. The capital city is found in the small county in the east of the island which is the darkest shade in each of the six plots, the suggestion being that workers have been slower to return to work in Dublin, with the hypothesis being that the more technical jobs found there are more amenable to ‘working-from-home’ and this development will prove interesting to follow as the country further moves out of restrictions.

The equivalent statistics in the case of residential areas are shown in Figure 3, where the grey areas represent counties in which there wasn’t enough data to provide a statistically significant estimate. These show the opposite effect to that found in the workplace requests as to be expected with people having to stay at home if they cannot go to the workplace. But again, the gradual return to the original baseline can be seen as we move forward in time and restrictions ease suggesting a return to some form of normality for the Irish population.

Google Residential Data

Summary

The availability of previously sensitive data offers fantastic opportunities for the applied mathematics community to provide analysis to society on the effect Covid-19 has had while also offering the potential to be included in technical models being used to describe the spreading process and how it is changing as these restriction measures fluctuate. It is also fascinating to get a small insight into the data which is available to these large corporations as a result of the use of their services and how they may be learnt from. Positively, it appears from these two separate sources that Irish daily life is slowly returning to where it was prior to the commencement of restrictions as the speed at which the virus spreads has been slowed with such great effect which one hopes to remain the case as society progresses in the future.

This article originally appeared on the ECMI (European Consortium for Mathematics in Industry), the article can be found here.

The maths of fantasy football

Thu, 12 Sep 2019 00:00:00 +0000

The Premier League is back. The season kicked off in August with last season’s runners-up Liverpool giving newly promoted Norwich City a tough introductory lesson in the form of a 4-1 defeat. The Reds' talisman Mo Salah scored their second goal, before assisting Virgil van Dijk for their third. While this performance no doubt thrilled Liverpool fans, there was also another group of people who were just as (if not more) delighted with the display. That’s the 44.7% of Fantasy Premier League managers who had Salah in their team.

For the uninitiated, Fantasy Premier League (commonly referred to as Fantasy Football) is an online game where six million users are provided with a virtual £100 million budget to assemble a squad of 15 real-life Premier League footballers from the 20 teams in the league. Each player has two characteristics: (a) their position - goalkeeper (GK), defender (DEF), midfielder (MID), or forward (FWD), and (b) the price one must pay to have them in their team.

The user must select two GKs, five DEFs, five MIDs and three FWDs while remaining on budget. Once the squad is ready, the user then proceeds to choose their 11 starting players, each of whom will score points as a result of their statistical performance in the physical matches they appear in with their team that Gameweek (GW). Users also nominate one of their players to be the team’s captain, which means that their point total is doubled that week.

At the end of the GW, each team’s points are tallied and users are given a ranking, process which repeats throughout the season. The challenge of the game is to determine an optimal way of spending your budget as to maximise your points.

How my team looked over the first GW of this season, giving me a total of 82 points and a measly rank of 839,678

During the off-season, researchers at MACSI in the University of Limerick undertook a large data scraping exercise to obtain the information of the top one million ranked players and their teams over the course of last season. We did so in the hope of gaining some insight into what characteristics and actions make a successful Fantasy Premier League “manager”. Specifically, we want to look at the different actions taken by those users that finished in the top 10K positions, in comparison to the moves made by the rest of the top million users.

Let’s focus on one element of the game, namely the manager’s use of chips. No, I’m not referring to their diet, but rather the three special Gameweek chips in the game itself. These allow users to have special privileges during the week that chip is played.

Due to the hectic nature of the English football season, there are occasions when fixtures must be rearranged known in Fantasy Football as Blank Gameweeks and Double Gameweeks.

Blank Gameweeks are GWs in which there are less than the usual ten fixtures as a result of fixture postponement. This occurred in 2017/18 in GW 27, 31 and 33 where there was only eight, five and six fixtures respectively. These weeks can make it difficult for users to field a full team of 11 playing players.

Double Gameweeks occur when teams who have fixtures postponed must play two matches in a GW. These offer prime opportunities to make extra points as players now have twice the opportunity to earn more points. Last season, these occurred in GW 32, 34 and 35, when there were a whopping 15, 11 and 14 games played.

The most successful chip strategy from last season was the Bench Boost. You choose a team of 11 starting players from your squad of 15 players and the remaining four are what are known as bench players. The point scores of these bench players don’t contribute to your GW total aside from the week in which one plays their bench boost chip. It would appear that if one’s bench players were going to receive points then the ideal time to use this chip would be when each of these players may play twice (to maximize the potential upswing from the chip) i.e., during one of the double GWs. Our analysis as seen in the following graph supports this claim:

Usage of the Bench Boost chip across the gameweeks last season for top 10k managers compared to the top 1 million.

You can see how a massive 79% of the players in the top 10k used the bench boost chip in GW 35 (the week of the season where there were the most fixtures). This compared to only 29% of those in the top 1 million. In fact, less than 10% of top 10k users had used the chip prior to this GW, a figure which the top 1 million surpassed by GW 14! The result? The top 10k users were much more likely to have obtained a higher point total from this chip (23.16) than the remaining players in the top 1 million (13.82).

In Fantasy Football, users can make only one free transfer in any GW, which allows them to exchange one of their players for another player in the game (provided they can afford them). The Free Hit chip allows the user to make unlimited transfers for that week. They could choose a new squad of 15 if they so pleased, but their team then reverts to how it was at the start of the week.

There tends to be two schools of thought within the Fantasy Football community as to what is the best way to use this chip. Should one use it during a blank GW when a large number of their players might not have a game? Or target the double GWs, because they have the chance of essentially hand-picking players appearing in 22 games (if their 11 starters all have two matches)?

Usage of the Free Hit chip across the gameweeks last season for top 10k managers compared to the top 1 million.

Our analysis (above) looked into what was the best strategy last season. 33% of users in the top 1 million had used this chip prior to GW 27 i.e. before any of the blank/double GWs came into play, which pales with the 7% of top 10k. We found that a massive 33% of the top million used it in GW 31, the week with the fewest fixtures, in comparison with 17% of the top 10k.

The other considerable GW which featured the chips use was GW 32, the large double Gameweek, with 69% of those who finished in the top 10k choosing to use the chip then, compared with only 15% of the remaining users. The top 10k generally received more points from this chip with a mean points value of 84.7, compared to 60.5 for the top million users. This suggests the strategy of using the chip during a large double GW was most definitely the best approach to take last season.

Each Gameweek, the user nominates one of their players to be the team’s captain, which means that their point total is doubled that week. The Triple Captain chip simply increases this to a factor of three. This is arguably the chip which offers the most uncertain returns, because not only does one have the option of which GW to use the chip but also the choice of player to give the virtual armband to.

The temptation to use this chip during a double GW (eg Sergio Aguero for Manchester City versus Fulham and Cardiff City in GW 32) is obviously very enticing since the player would have two games from which they could return triple gains. However, if their team has two difficult fixtures it may not prove to be worthwhile, and one may instead prefer to use it during a normal single GW where the player has an appealing fixture (e.g., Salah for Liverpool versus Huddersfield Town in GW 36). A third option that is commonly mentioned is to use the chip in the final GW where many teams have nothing to play for and can result in high score-lines (e.g., Nathan Redmond for Southampton vs. Huddersfield in GW 38).

Usage of the Triple Captain chip across the gameweeks last season for top 10k managers compared to the top 1 million.

Investigating the data found a variety of strategies for this chip at different points in the season. Once again, we highlight the fact that while only 6% of top 10k users had used their triple captain chip by GW24, a considerable 25% of the remaining players had done so at the same point. In terms of the GW in which it was most commonly used, we found that 43% of top 10k users used it in GW 36, which interestingly was a single GW (where Liverpool had a very attractive game in terms of difficulty). 29% of the top 1 million decided that the double GW 32 was the optimal time to play the chip.

In terms of the range of scores obtained, it appears that the triple captain chip offers the least in terms of total number of points, which in some way is to be expected as it only provides an increase for a single player. We found that the triple captain chip resulted in a mean score of 11.5 for the top 10k and 8.67 for the other group.

For Fantasy Football managers looking for tips regarding the optimal way to use their chips, here are some suggestions from the data

Save your chips! While it is very tempting to use a chip at an early stage in the season to get the top spot in your league, we can see from last season’s data that good users saved their chips until the last 10 weeks in the season to make the most of the blank and double GWs.
There are generally two large double GWs and these are prime times to use your chips to maximise your returns, especially the Bench Boost. Almost 80% of top 10k managers used this strategy.
Don’t be afraid to play your Triple Captain chip in a single GW. It is very tempting to use the chip during a double GW, where the player has two opportunities to score points. But if the fixtures aren’t great for the player, it is arguably better to use it in a single GW where they have a nice fixture as shown by the top 10k using the chip in GW 36 when Liverpool played Huddersfield.

This project is still very much a work in progress and any comments or suggestions of potential research avenues will be greatly appreciated. We hope that all the managers considering their options throughout this season have found some useful information to help them climb up the leader board with our analysis of the different chips. It’s worth noting that while these strategies performed well during last season for the top 10k, this is not to say the same will happen this season. Of course, you’re free to trust them blindly, which may result in an improvement of your own overall rank.

This article originally appeared on RTE Brainstorm, the article can be found here.