0. How to use these notes

  • Think of this as a mini-chapter on correctness.
  • Anything marked REMEMBER or CORE SENTENCE is an interview line.
  • If you can explain every section in your own words, you cover ≈80% of validation questions.

1. Why correctness and validation matter

A unified pricing and risk library is not a toy.

  • Trading, risk, P&L, limits, and sometimes capital all depend on its numbers.
  • Small mistakes scale into big exposures when you aggregate over portfolios and time.
  • If the library drifts silently, you get:
    • unexplained P&L,
    • broken hedges,
    • model risk issues and audit findings.

CORE SENTENCE: “The hardest part is not coding a pricer once, but keeping its behaviour stable and explainable as the system evolves.”

“Correctness” is not absolute. It means:

  • consistent with:
    • contract terms,
    • market inputs,
    • model assumptions,
    • known analytical results,
    • and basic economic sense.

“Validation” is the discipline of checking that, repeatedly.

2. Minimum validation toolkit

You want to be able to rattle these off without thinking:

  1. Unit tests for payoffs and edge cases.
  2. Golden regression tests (locked inputs → locked outputs).
  3. Finite-difference checks for Greeks vs analytic sensitivities.
  4. Sanity checks (monotonicity, sign, bounds).
  5. Reproducibility checks (same snapshot + same code version → same output).

We go through each.

2.1 Unit tests for payoffs and edge cases

What they are

  • Small, deterministic tests that check:
    • the payoff logic of instruments,
    • special cases (ATM, deep ITM/OTM, zero notional, zero volatility, zero time-to-maturity).

Examples:

  • European call payoff:
    • for spot S and strike K:
      • if S > K, payoff = S − K;
      • if S ≤ K, payoff = 0.
    • test several points: [K−1, K, K+1].
  • Digital option:
    • payoff is either 0 or 1, never negative.
  • Swap cash flows:
    • notional times accrual factor times rate, with correct date conventions.

Edge cases:

  • zero notional → zero PV, zero Greeks.
  • zero time to maturity:
    • option price → immediate payoff (under suitable assumptions).
  • extreme parameters:
    • very low or high volatility within reason.

REMEMBER: “Unit tests pin down payoff logic and special cases so we know exactly what the code does at the edges.”

2.2 Golden regression tests

Idea

  • Fix inputs and expected outputs for a set of representative trades.
  • Store them as “golden” results.
  • Future code changes must either:
    • reproduce them within tolerance, or
    • intentionally update them with justification.

What you lock:

  • A set of reference trades:
    • plain vanilla options, swaps, forwards, simple structured payoffs.
  • A versioned market snapshot:
    • curves, vols, fixings.
  • A model configuration:
    • model type, parameters or calibration.
  • Expected:
    • price, key Greeks, possibly other diagnostics.

The tests:

  • feed the exact same:
    • trade, market snapshot ID, model ID, pricer settings,
  • assert that outputs are within small tolerances of the golden record.

REMEMBER: “Golden regression tests turn the library’s behaviour into an artefact. Any change in those numbers must be deliberate.”

2.3 Finite-difference checks for Greeks

Why

  • Many pricers provide analytic Greeks.
  • You need confidence that they match the actual sensitivity of price to inputs.

Method

For each Greek, e.g. delta:

  • Choose a small bump h on the underlying (spot).
  • Compute:
    • price_plus = P(S + h),
    • price_minus = P(S − h) (for central difference),
    • approximate delta ≈ (price_plus − price_minus) / (2h).
  • Compare this to the analytic delta reported by the pricer.

Key details:

  • h must be:
    • small enough so linear approximation is valid,
    • large enough to avoid numerical cancellation noise.
  • For Monte Carlo:
    • reuse the same random seed for price_plus and price_minus if possible:
      • reduces noise in finite differences.

You do the same for:

  • gamma (second derivative),
  • vega (volatility bump),
  • rho (rate bump),
  • theta (forward difference in time).

CORE SENTENCE: “I routinely cross-check analytic Greeks with finite differences to catch sign errors, missing terms, or broken chain rules.”

2.4 Sanity checks: monotonicity, sign, bounds

What

These are economic sanity checks that catch entire classes of bugs.

Examples:

  • Monotonicity in strike:
    • For calls:
      • price should decrease as strike increases, all else equal.
    • For puts:
      • price should increase as strike increases.
  • Monotonicity in maturity:
    • With positive rates and non-negative vol, option value should not drop dramatically with longer maturity.
  • Sign checks:
    • long positions should not have negative PV under zero risk-neutral drift and zero risk premia in toy test cases.
    • vol should not be negative; discount factors should be in (0, 1].
  • Bounds:
    • Call price between:
      • max(S − K·DF, 0) and S.
    • Put price between:
      • max(K·DF − S, 0) and K·DF.
    • Probabilities between 0 and 1, sums of probabilities = 1.

You can implement these as tests:

  • scanning over grids of parameters,
  • asserting inequalities hold everywhere (within numerical noise).

REMEMBER: “Monotonicity, sign, and bounds tests are cheap ways to catch deep mistakes. If they fail, something is seriously wrong.”

2.5 Reproducibility checks

Goal

  • Same inputs + same code version → same outputs. Always.

What you enforce:

  • All non-determinism controlled via explicit seeds:
    • Monte Carlo random numbers.
    • Any random initialisations.
  • No hidden dependence on:
    • system time,
    • “current date” not passed as argument,
    • global state like “last used snapshot”.

Checks:

  • Run the same regression suite twice with the same configuration:
    • expect identical outputs (for deterministic methods),
    • or differences well within known Monte Carlo confidence intervals.
  • Exercise a full run in CI:
    • verify that only intended changes modify outputs.

CORE SENTENCE: “I treat pricing like a scientific instrument: versioned inputs, deterministic outputs, and regression tests that detect drift.”

That is the sentence you want to actually say.

3. Connecting this to your model risk experience

You have a strong advantage: years of model risk and validation work.

Reframe it in interview language:

  • “I have seen how models fail in production.”
    • model misspecification,
    • miscalibration,
    • data errors,
    • wrong use-cases.
  • “I know how drift happens.”
    • slow data changes,
    • silent code changes,
    • environment changes (libraries, compilers).
  • “I know what governance expects.”
    • traceability,
    • documentation,
    • independent reviews,
    • sign-offs and version control.

CORE SENTENCE: “My banking career in model risk taught me how models fail and what governance expects. I use that to build trading analytics that are stable, traceable, and defensible.”

This is powerful because many quant devs can code but cannot articulate governance and validation.

4. 30-minute question: “How do you validate a pricer?”

You want a structured answer. Think of layers:

4.1 Layer 1 – Unit and payoff tests

  • Start by validating instrument logic:
    • payoffs and cash flows for simple deterministic scenarios.
  • Check edge cases:
    • maturity zero,
    • zero vol,
    • extreme strikes,
    • zero and negative rates if allowed.

4.2 Layer 2 – Known analytical benchmarks

  • Compare against closed-form solutions where available:
    • binomial vs Black–Scholes,
    • simple swap vs discounted cash-flow formula.
  • Validate convergence:
    • as you increase time steps or grid resolution,
    • numerical method converges to analytical benchmark.

4.3 Layer 3 – Sanity and arbitrage checks

  • Check monotonicity, sign, and bounds.
  • Check no simple static arbitrage:
    • put–call parity,
    • forward–spot–rate consistency,
    • calendar spreads.

4.4 Layer 4 – Regression suite

  • Lock golden results for:
    • carefully chosen set of trades and snapshots,
    • multiple model configurations.
  • Use them to detect drift whenever the pricer or dependencies change.

4.5 Layer 5 – Cross-model and back-to-back checks

  • Where possible:
    • cross-check different numerical methods:
      • PDE vs MC,
      • lattice vs closed-form.
  • For complex products:
    • check a simplified version that reduces to something known.

Put it together:

Sample answer: “I validate pricers in layers. First I pin down payoff logic and edge cases with unit tests. Then I compare against analytical benchmarks and confirm convergence as I refine grids or steps. I run economic sanity checks like monotonicity and no-arbitrage bounds. Finally, I maintain a regression suite of reference trades and snapshots so that any change in behaviour is visible and must be justified.”

5. 30-minute question: “How do you prevent accidental changes in pricing outputs?”

Answer in terms of process + tooling.

5.1 Golden regressions and CI

  • Regression tests for key trades:
    • run on every PR / commit.
  • CI fails if:
    • prices or Greeks move beyond defined tolerances.

5.2 Protected main and code review

  • Protected main:
    • no one can bypass regression tests.
  • Code review:
    • reviewers look at both code and impact on outputs:
      • diff of regression suite results.

5.3 Controlled versioning

  • Library releases with:
    • version number,
    • changelog listing:
      • “pricing behaviour changes”,
      • “bug fixes that impact PV / Greeks”.
  • Model changes treated as:
    • explicit releases, not silent tweaks.

5.4 Environment control

  • Pin versions of:
    • dependencies (math libs, random generators),
    • compilers, if relevant.
  • Avoid “surprise upgrades” in production.

Sample answer: “We prevent accidental changes by locking in golden regression tests and running them in CI for every change. Main is protected, so you cannot merge code that moves prices or Greeks beyond tolerances. We release the library as a versioned package with a changelog, and model changes are treated as explicit releases, not silent updates. Combined, this makes pricing drift visible and controllable.”

6. Deep technical: “What’s your approach for testing Monte Carlo models?”

Monte Carlo is inherently noisy. Your answer must show you respect that.

6.1 Determinism via seeding

  • Use fixed seeds in tests:
    • same seed → reproducible streams of random numbers.
  • For finite-difference Greeks:
    • use common random numbers:
      • reuse the same random draws for bumped scenarios.

6.2 Convergence to analytical benchmarks

  • For products with analytic or semi-analytic solutions:
    • price them with MC for increasing number of paths N:
      • track bias and standard error.
  • Check:
    • mean MC estimate converges to analytic price.
    • estimated standard error scales like 1/√N.

6.3 Confidence intervals and tolerance

  • For each test:
    • compute estimated standard error (σ_est/√N).
    • form confidence intervals (e.g. 95% CI).
  • Assert:
    • analytic price lies within CI,
    • or difference is less than a multiple of the standard error.

6.4 Path diagnostics

  • Test the underlying path generator:
    • distributions at single time steps (mean, variance vs theory),
    • correlations between dimensions,
    • marginal distributions for Brownian increments.

6.5 Regression and performance

  • Keep a small Monte Carlo regression suite with fixed seeds.
  • Use it to:
    • detect algorithmic changes (variance reduction, new discretisation),
    • compare performance vs accuracy.

CORE SENTENCE: “For Monte Carlo, I test both the path generator and the pricing layer: convergence to analytical benchmarks, confidence interval coverage, and deterministic results under fixed seeds.”

7. Deep technical: “How do you set tolerances for numerical regression tests?”

This is subtle. You must show you balance strictness and robustness.

7.1 Absolute vs relative tolerance

  • Absolute tolerance:
    • suitable when magnitudes are small or bounded (e.g. price near zero).
  • Relative tolerance:
    • suitable when magnitudes vary widely (e.g. PV of large notional trades).

Typical pattern:

  • Use a combination:
    • |new − old| ≤ abs_tol + rel_tol · |old|.

7.2 Instrument scale and units

  • Tolerances must make sense relative to:
    • notional size,
    • typical PV magnitude,
    • currency units.
  • For example:
    • a one-cent difference on a small retail option is fine;
    • a 1% change on a large swap PV is not.

7.3 Method and noise sources

  • Deterministic methods:
    • PDE, analytic formulas, lattice with fixed steps:
      • expect very tight tolerances:
        • differences mainly from floating-point rounding.
  • Monte Carlo:
    • tolerances must account for sampling error:
      • correlate them with estimated standard error.

7.4 Intentional vs accidental changes

  • For expected changes (e.g. bug fixes, new features):
    • update golden values and document in changelog.
    • sometimes widen tolerances slightly for known rounding changes.
  • For accidental changes:
    • tests fail,
    • investigate before updating expectations.

Sample answer: “I choose tolerances relative to trade scale and numerical method. For deterministic pricers, tolerances are tight and based on floating-point limits. For Monte Carlo, I use the estimated standard error to calibrate tolerances, often combining absolute and relative thresholds. A typical rule is |ΔPV| ≤ abs_tol + rel_tol·|PV|, and any test that fails triggers investigation before we update regression expectations.”

8. Cheat sheet – sentences to memorise

You should be able to recall these on demand:

  1. Validation toolkit

    “My basic toolkit is unit tests for payoffs, golden regression tests, finite-difference checks for Greeks, economic sanity checks, and reproducibility checks.”

  2. Scientific instrument line

    “I treat pricing like a scientific instrument: versioned inputs, deterministic outputs, and regression tests that detect drift.”

  3. Model risk link

    “My model risk background taught me how models fail and what governance expects; I apply that discipline to trading analytics so the library stays trustworthy.”

  4. Validate a pricer

    “I validate a pricer in layers: payoff and edge-case tests, analytical benchmarks and convergence, no-arbitrage sanity checks, and a locked regression suite.”

  5. Prevent accidental changes

    “Accidental changes are caught by regression tests in CI, protected main, and versioned releases with explicit notes on any pricing behaviour changes.”

  6. Test Monte Carlo

    “For Monte Carlo, I fix seeds, test the path generator, check convergence to analytical benchmarks, and use confidence intervals to set tolerances.”

  7. Set tolerances

    “Tolerances are a mix of absolute and relative thresholds, scaled to trade size and numerical noise; deterministic pricers get tight tolerances, Monte Carlo pricers get tolerances linked to sampling error.”