A textbook model and a trading desk usually disagree because the textbook prices an idealised contract, while the desk prices the contract that actually trades. The formula is often fine. What it leaves out are the market conventions, settlement lags, holiday calendars and date adjustments that determine when cash actually moves. Those details look trivial on paper. On a live trade they are worth real money, and a model that ignores them will produce a price no counterparty will honour.

Formula → Conventions → Calendars → Price

I use this sequence because it shows where the gap opens. Most people who build or review a pricing model stop after the first step. The desk lives in the last one. The money that separates the two sits in the middle.

The formula is the easy part

Every analyst who has opened a derivatives textbook has seen the clean version of an FX forward. You take spot, apply the interest rate differential over the life of the trade, and you have a forward rate. It is elegant, it is correct as far as it goes, and it is how most of us were taught.

The trouble is that the formula assumes time is continuous and frictionless. It treats "one year" as a number rather than a specific sequence of business days between two specific settlement dates in two specific currencies. That simplification is reasonable for teaching. It is not reasonable for a price you intend to trade on.

I recently spoke with Dominic O'Kane on Stack to Street. He is the former head of quant research at Lehman Brothers Europe and the creator of the open-source FinancePy library. He described this exact gap as one of the reasons he built the library. He used the FX forward as his example, the simplest trade in the book. He pointed out that spot FX settles one or two days after trade date depending on the currency pair, and that textbooks rarely mention it. "It's a minor detail," he said in our conversation. "But if you're sitting on a trading floor, that minor detail has financial value."

That sentence explains most model-versus-desk disputes I have seen.

Conventions: where the textbook goes quiet

Conventions are the agreed rules that turn an abstract contract into a tradeable one. They cover how many days spot takes to settle, how interest accrues, which day-count basis applies, and how a date that falls on a weekend gets rolled. None of these is a modelling breakthrough. Each one is a rule that both sides of a trade have agreed to follow, and the price depends on applying them correctly.

For an institution, the important point is that conventions are not optional refinements to be added once the "real" model is done. They are part of the contract definition. A forward priced off the wrong spot date is a price for a different instrument. If your analyst's spreadsheet and the dealer's system disagree, the first question should not be about volatility or curve construction. It should be about whether both are pricing the same dates.

In my experience, executives tend to assume that pricing discrepancies come from sophisticated disagreements about models. Usually they come from mundane disagreements about definitions.

Calendars: the tedious detail that carries money

Calendars are where conventions meet the real world. A settlement date has to be a business day in the relevant financial centres. When it is not, it moves according to an adjustment rule. A cross-currency trade may need to respect holidays in two or more jurisdictions at once. Get one holiday wrong and the settlement date shifts, the accrual period changes and the price changes with it.

Dominic was candid about how unglamorous this work is. He implemented holiday calendars for twenty countries in FinancePy and described it as "tedious and boring detail." He was equally clear about why it matters: on a trading floor, if you get that wrong, "you can lose several thousand dollars on a trade the minute you do the trade."

That point deserves attention from anyone who oversees a trading, treasury or risk function. A calendar error is not a slow leak that shows up at quarter end. The loss crystallises at execution. And because calendar logic is buried deep in systems and rarely questioned, the same error can repeat across thousands of trades before anyone traces it back.

Price: what the desk actually quotes

By the time a desk quotes a price, it has passed the formula through every convention and calendar adjustment that applies. It may also reflect practical constraints that never appear in a textbook. Dominic described how quants routinely simplify sophisticated models so that overnight risk runs finish in time for traders to hedge the next morning. He also described how desks hold back profit as reserves when a key input such as correlation cannot be hedged or observed. As he noted, "you never read about this in finance books."

So the desk price is the formula plus the plumbing plus the operational judgement of the institution. When a model disagrees with it, the model is usually missing one of those layers rather than getting the core mathematics wrong.

Why this matters beyond the trading floor

This gap is not only a quant's problem. It affects several groups inside a financial institution:

Historically, the reference points for these checks were either internal systems that few people could read or vendor terminals whose internals were not visible. Dominic made the point directly when describing how a buy-side analyst might use FinancePy: "Bloomberg is a black box." A transparent library lets you try to reproduce a vendor number and then see exactly which assumption drives any difference.

This is why I think open-source financial libraries matter more than their download counts suggest. FinancePy is designed so that a user can follow a calculation down through two or three layers of readable Python and see where every number comes from. Dominic also argued that a widely inspected open model becomes a benchmark: if your result matches a number that many people have scrutinised, you have reasonable grounds for confidence in it. That is a different basis for trust than relying on a single proprietary system.

AI changes who can close the gap

There is a broader shift here that I think institutions are underestimating. Reconciling a model price with a desk price used to require someone who understood both the finance and the code. Those people were scarce, and they sat in quant teams.

AI coding tools are changing that. A treasury analyst or risk manager who understands what a spot lag or a holiday roll is can now ask an AI assistant to walk through an unfamiliar library, locate the calendar logic and test what happens when a date convention changes. The barrier is moving from "Can I program this?" to "Do I understand the financial problem well enough to ask the right question?"

That shift favours people with domain knowledge. Institutions are full of people who know exactly why a forward should settle on a particular day but could never previously verify it in code. Transparent libraries combined with AI assistance give them a way to do so.

A practical checklist

When a model price and a desk price disagree, I would work through the framework in order:

  1. Confirm the formula. Make sure both sides are pricing the same instrument with the same core methodology.
  2. Check the conventions. Verify the spot settlement lag, day-count basis and business-day adjustment rule.
  3. Check the calendars. Confirm which holiday calendars apply, for which centres, and whether any date in the schedule has been rolled.
  4. Reconcile the dates first, then the inputs. Compare settlement, accrual and maturity dates before arguing about curves or volatility.
  5. Ask about desk-specific adjustments. Find out whether the quoted price includes reserves, approximations or other practical constraints.
  6. Benchmark against a transparent implementation. Use a library whose calculations you can read, so the source of any difference is visible rather than assumed.

The formula gets the attention, but the money is in the conventions and calendars. Institutions that treat those details as core parts of the contract rather than minor footnotes will spend less time on unresolved pricing disputes and lose less money at execution.

At Path66 and on Stack to Street, I keep returning to the same theme: the tools that close these gaps are increasingly open, inspectable and accessible to people who understand the business. The full conversation with Dominic is available on the episode page for anyone who wants to go deeper.

About the author

Michael McLaughlin has more than 30 years in structured finance and private credit. At Macquarie Group from 2008 to 2023, he built the credit markets business from inception into a portfolio financing platform that averaged a $5 billion portfolio and generated more than $1 billion in cumulative net revenue. He has advised Hebbia on AI research software for financial services, and builds his own finance applications with AI coding tools and open-source software.

Through Path66, Michael works with financial institutions and investment firms on asset finance, liquidity, capital raising, data-driven due diligence and the practical application of emerging technology in finance. He hosts Stack to Street, where he interviews the developers building the software that will change financial institutions. Full bio.

Source

From Physics to Wall Street, Stack to Street with Dominic O'Kane, Creator of FinancePy. Full transcript on the episode page.