• AQH Weekly Deep Dive
  • Posts
  • Quant Analytics for Trading & Execution — Who Sets the Price When Nobody's Quoting?

Quant Analytics for Trading & Execution — Who Sets the Price When Nobody's Quoting?

AlgoQuantHub Weekly Deep Dive

Author

Nicholas Burgess
August 21, 2026

Welcome to the Deep Dive!

Each week on The Deep Dive we explore cutting-edge ideas in algorithmic trading, quantitative research, and modern financial engineering, bridging theory and practice in how markets behave.

This week we explore: the importance of Quant Analytics for trading, execution, pricing and risk. We explore why, when liquidity thins, price stops being something you observe and becomes something you have to manufacture, discover and quote — and what that demands of your analytics.

Table of Contents

Feature Article: When Liquidity Thins, the Price Discovery Mechanism Becomes Your Quant Analytics

The conventional mental model is that the market produces the price and the model merely marks it. You look at the screen, take the mid, and your analytics tell you whether the level is rich or cheap. Valuation sits downstream of price. In genuinely liquid markets this is approximately true — continuous two-way flow means the observable price has already aggregated every participant's model, and your own theoretical value adds little beyond a sanity check. Under this view, analytics is a reporting function: useful for risk, useful for P&L attribution, but not for execution.

That model breaks down precisely when it matters most: off-the-run bonds, thin option strikes, month-end, holiday sessions, credit stress. In these regimes the screen level is indicative, not firm — a soft advertisement rather than a commitment — and the depth behind it may be a fraction of your intended size. What the price-taker view misses is that these quotes are not produced by an anonymous aggregation of thousands of participants; they are produced by a handful of desks, each running their own curve and their own model. Price here is endogenous, not exogenous. The market price is being generated by the pricing models, inventory, risk appetite, and decisions of the dealers participating in the trade — rather than existing as an independent, observable market fact that everyone simply accepts. The mechanism is not aggregation but anchoring: whoever can produce a defensible theoretical value fastest supplies the reference point around which the negotiation happens. Request for Quotes (RFQs) make this explicit — you request, a dealer responds, and the gap between their firm quote and your theoretical value is not noise. It is the liquidity cost you are being asked to pay, itemised.

The implication is that your analytics infrastructure is a portfolio-management input, not a back-office utility. If your curve build takes seconds, your risk comes from bumping and re-pricing, and your Excel layer dies on an access violation halfway through, you cannot participate in that negotiation at the speed it happens — you become a price taker by default and you pay the spread as a tax on slowness. If your curves calibrate in milliseconds with an analytic Jacobian giving exact risk, the position changes: you can make markets around the theoretical, walk an order down the book with a known reservation level, and treat an indicative screen level as a hypothesis to be tested rather than a fact to be accepted. Practically, the discipline to adopt is this — mark every fill against your theoretical value at the moment of execution, not against the end-of-day close. That execution-versus-model gap, tracked over time, is the single number that tells you whether you are being paid for supplying liquidity or quietly paying to consume it.

Keywords: Price Discovery, Endogenous Pricing, RFQ Execution, Liquidity Cost, Analytic Risk Jacobian — Fixed Income, Credit & Rates

Bonus Article: Rebuilding the Quant Stack — VS2017 → VS2022, Incorporating AI and Why I Dropped a $1,000 Excel Layer

Why it matters: the feature article's argument is only as good as the machinery underneath it. This week I rebuilt that machinery for my AlgoQuant library (AQ Lib) that supports real-time electronic trading.

The core job was migrating my rates, fixed income and credit analytics library from Visual Studio 2017 to Visual Studio 2022 — a newer toolset, newer language features, and, critically, an environment where AI tooling (Copilot, Claude) can actually reach into the codebase. That meant rebuilding every dependency against the new toolchain: Boost, QuantLib, GoogleTest and the AAD libraries used for real-time analytical risk, all matched to the static runtime the library links against. The larger decision was to replace the Excel layer. I had been using XLL Plus by Planatech — an excellent commercial product that is advanced, user-friendly and amazing to work with, but one whose per-seat licence cost is passed straight through to anyone who wants to use the library.

I moved to xlOil, which is free, open source and used by QuantLib. I kept my own rich object-handle framework underneath it. The xlOil handles registration and marshalling, my layer handles object lifetime, copy/modify/delete semantics, and short numeric sheet handles that force Excel's dependency tree to recalculate correctly. In xlOil's C++ layer the registration boilerplate collapses to roughly this shape: 

XLO_FUNC_START( aqDiscountFactor(
    const ExcelObj& curveHandle,
    const ExcelObj& maturity) )
{
    auto curve = ObjStore::get<YieldCurve>(curveHandle.toString());
    return ExcelObj(curve->discount(toDate(maturity))).release();
}
XLO_FUNC_END(aqDiscountFactor)
    .threadsafe()
    .help(L"Discount factor from a calibrated curve")
    .arg(L"CurveHandle", L"Handle returned by aqBuildCurve")
    .arg(L"Maturity",    L"Maturity date");

As for upgrading the Quant Analytics from Visual Studio 2017 to 2022 the build steps are, in order: (1) retarget the solution and toolset, (2) rebuild every dependency with matching runtime flags, (3) swap the registration layer, (4) keep SEH structured exception handling in place so an access violation surfaces as a readable error rather than taking Excel down with it, (5) re-run the full regression suite with automatic rebaselining, (6) re-profile for speed, hotspots and leaks. Full rebuild: five minutes.

The takeaway is not really about Excel and besides Quant analytics libraries need to support many API bindings: C#, Java, Python, … as well Excel. It is that your toolchain choice determines who can help you — including the machines. A codebase pinned to a 2017 toolset with a commercial dependency in the presentation layer is a codebase that AI assistants read poorly, that users must pay to access, and that quietly accumulates a migration debt you eventually pay all at once. Modernising the toolset was the enabler for everything else: better compiler diagnostics, current language features, and an environment where an LLM can meaningfully participate in refactoring and test generation. Removing the commercial Excel dependency removed a cost barrier for every future user of the library.

Pleasingly, I am not alone in this — Sebastian Schlenkrich has published an Excel interface for QuantLib built on xlOil, and BN Algorithms now recommends xlOil as the preferred route into Excel for QuantLib. The convergence is a signal: the industry is quietly standardising on a free, maintainable Excel layer with the pricing engine kept cleanly separate underneath. If you are still maintaining a bespoke XLL wrapper, that is the direction of travel.

More detailed implementation frameworks and structured trading models are available in my AlgoQuant playbooks and trading toolkits.

Keywords: Toolchain Modernisation, AI, Copilot, Claude, Visual Studio, QuantLib, xlOil, XLL Add-ins, SEH, Swaps, CDS, Pricing, AAD Analytic Risk — Quant Library Engineering

AlgoQuant Playbooks & Trading Toolkits

Explore my quantitative trading and financial markets toolkit store, featuring practical implementation frameworks for yield curve construction, derivatives pricing, risk modelling, and live market trading.

Feedback & Requests

I’d love your feedback to help shape future content to best serve your needs. You can reach me at [email protected]