Chapter 1 — Why OCaml for Quantitative Finance?

"A language that doesn't affect the way you think about programming is not worth knowing." — Alan Perlis

Jane Street Capital is one of the most quantitatively sophisticated trading firms in the world, responsible for a significant fraction of US equity market volume on many trading days. Its entire technology stack — from market data feeds to execution algorithms to risk systems — is written in OCaml. When this became widely known in the mid-2000s, it prompted a question that practitioners still ask: why would a firm that depends on fast, reliable, correct software choose to build everything in a language that most finance professionals have never heard of?

The short answer is that OCaml combines properties that quantitative finance uniquely needs: a static type system powerful enough to make many financial modelling errors impossible at compile time; a functional programming model that naturally expresses the mathematical structure of financial computations; a native-code compiler that generates performance competitive with C++; and an ecosystem of production-grade libraries developed by practitioners for practitioners. Python, the dominant language in quantitative research, provides none of the first two and sacrifices the third for development convenience.

This chapter makes the case for OCaml as a financial programming language through concrete comparisons and real examples. We examine the language landscape, identify where each language excels and falls short, and demonstrate through side-by-side comparisons how OCaml's type system and functional features translate directly into safer and more maintainable financial code. We end with a quick-start section to get a working OCaml environment ready for the rest of the book.

1.1 The Language Landscape in Finance

Walk into any quantitative finance department and you will find three languages doing the heavy lifting:

Python dominates research and data analysis. Its ecosystem — NumPy, pandas, SciPy, scikit-learn — is unmatched for rapid prototyping. A quant can bootstrap a factor model or price an exotic option in an afternoon. The cost is performance and correctness: Python's dynamic typing means bugs that a compiler would catch in milliseconds survive until production.

C++ dominates latency-sensitive production systems. A well-optimised C++ pricer can run orders of magnitude faster than Python. The cost is development time, complexity, and a type system that permits many dangerous operations silently.

Java and C# occupy the middle tier: managed runtimes, strong typing, garbage collection, decent performance. They suffer from verbosity and a culture that discourages the functional style that makes financial modelling natural.

OCaml sits in a position none of these languages occupies: it offers ML-family expressive strength, a Hindley-Milner type system that infers types without annotation burden, performance approaching C++ for many workloads, and a garbage collector tuned for low-pause operation. It was born in the same research tradition as Haskell but prioritises practicality.

1.2 The Case for Static Types in Finance

Consider a simple bond pricing function. In Python:

def price_bond(face_value, coupon_rate, yield_rate, periods):
    pv = 0
    for t in range(1, periods + 1):
        pv += (face_value * coupon_rate) / (1 + yield_rate) ** t
    pv += face_value / (1 + yield_rate) ** periods
    return pv

Nothing stops a caller from passing a yield expressed as a percentage (5.0) rather than a decimal (0.05), or from passing a string, or from confusing face value with notional. These bugs are silent and can survive into production reports.

In OCaml:

type currency = USD | EUR | GBP
type rate = Rate of float  (* always a decimal, e.g. 0.05 *)
type periods = Periods of int

let price_bond ~face_value ~(coupon : rate) ~(yield : rate) ~(tenor : periods) =
  let Rate c = coupon in
  let Rate y = yield in
  let Periods n = tenor in
  let coupon_payment = face_value *. c in
  let discount t = 1.0 /. (1.0 +. y) ** float_of_int t in
  let coupon_pv = List.init n (fun i -> coupon_payment *. discount (i + 1))
                  |> List.fold_left (+.) 0.0 in
  coupon_pv +. face_value *. discount n

The type wrappers Rate and Periods make it structurally impossible to pass the wrong kind of value. The compiler enforces the contract. This matters enormously in a codebase where a single numerical error can mean millions of dollars.

1.2.1 Phantom Types for Unit Safety

A more powerful pattern uses phantom types to prevent unit confusion at zero runtime cost. The type parameter is never stored at runtime — it exists only for the compiler to enforce invariants at the call site.

Example 1 — Currency safety:

(* The type parameter 'ccy is never inhabited — it's a compile-time tag *)
type 'ccy amount = Amount of float

(* Abstract currency tags — these types have no values *)
type usd
type eur
type gbp

module Fx = struct
  (* A currency pair: 'from -> 'to, with an exchange rate *)
  type ('from, 'to_) rate = Rate of float

  (* Convert an amount from one currency to another *)
  let convert (Rate r) (Amount a) : 'to_ amount = Amount (a *. r)

  (* EUR/USD rate — tags encode direction *)
  let eurusd : (eur, usd) rate = Rate 1.085

  (* This compiles: convert EUR 1000 to USD *)
  let _usd_amount : usd amount = convert eurusd (Amount 1000.0 : eur amount)
end

(* Type error: cannot compare EUR and USD amounts directly *)
(* let _bad = (Amount 100.0 : usd amount) = (Amount 100.0 : eur amount) *)

Example 2 — Rate day-count basis:

Day-count conventions (Act/360, Act/365, 30/360) are one of the most common sources of silent errors in fixed income systems. An Act/360 rate silently substituted for an Act/365 rate produces incorrect coupon accruals. Phantom types close the loophole:

type act360
type act365
type thirty360

(* A rate tagged with its basis convention — same float, different type *)
type 'basis rate = Rate of float

(* Conversion between bases requires an explicit, named function *)
let act360_to_act365 (Rate r : act360 rate) : act365 rate =
  Rate (r *. (365.0 /. 360.0))

(* A swap pricer that demands the correct basis on each leg *)
let price_fixed_float_swap
    ~(fixed_rate : act365 rate)
    ~(float_rate : act360 rate)
    ~notional ~tenor =
  let Rate f = act360_to_act365 float_rate in   (* explicit conversion *)
  let Rate r = fixed_rate in
  notional *. tenor *. (r -. f)

(* Passing Act/365 as the float_rate leg is a compile-time error — not a
   silent mispricing buried in a coupon schedule produced days later. *)

Example 3 — Trade settlement state:

Trading systems must enforce a lifecycle: trades begin as pending, become confirmed on counterparty acknowledgment, and only then become settled. Only settled trades should generate ledger entries. Phantom types encode this lifecycle without runtime checks or mutable state flags:

type pending
type confirmed
type settled

(* A trade tagged with its current lifecycle state *)
type 'state trade = {
  instrument : string;
  notional   : float;
  trade_date : string;
}

(* State transitions: smart constructors that advance the phantom state *)
let confirm (t : pending trade) : confirmed trade =
  (t :> confirmed trade)   (* safe: same runtime layout *)

let settle (t : confirmed trade) : settled trade =
  (t :> settled trade)

(* Only settled trades can generate ledger entries *)
let post_ledger_entry (t : settled trade) =
  Printf.printf "Posting %.2f for %s\n" t.notional t.instrument

(* These are all compile-time errors — the type system enforces the lifecycle: *)
(* post_ledger_entry { instrument = "bond"; notional = 1e6; trade_date = "2026-01-01" } *)
(* ^^ Error: pending trade where settled trade was expected                              *)

In all three examples, the phantom type parameter is erased at compile time — the generated machine code is identical to a version with no type tags. The entire benefit is at the type-checking level, with no runtime overhead whatsoever. No other mainstream language achieves this combination: zero overhead, full inference, ergonomic syntax. C++ requires explicit template specialisations; Java's generics are erased but lack abstract type tags; Rust achieves a similar effect via its newtype pattern but requires more explicit annotation.

1.3 Functional Programming and Financial Models

Financial models are inherently mathematical: they describe transformations of values, not sequences of imperative mutations. Functional programming maps naturally onto this domain.

1.3.1 Composition

A pricing pipeline is a composition of functions:

$$\text{price} = \text{discount} \circ \text{payoff} \circ \text{simulate}$$

In OCaml:

let price_european ~pricing_date ~spot ~vol ~rate ~strike ~expiry ~payoff =
  let tau = Time.diff expiry pricing_date in
  spot
  |> simulate_gbm ~vol ~rate ~tau          (* S_T distribution *)
  |> payoff ~strike                         (* option payoff *)
  |> discount ~rate ~tau                    (* present value *)

Each stage is a pure function. The pipeline is testable at every intermediate point and trivially parallelisable.

1.3.2 Algebraic Data Types for Financial Instruments

OCaml's variant types model the discrete choices in financial instrument taxonomy with exhaustive pattern matching:

type option_type = Call | Put

type exercise_style =
  | European
  | American
  | Bermudan of { exercise_dates : Date.t list }

type barrier_type =
  | UpAndOut   of { barrier : float }
  | DownAndOut of { barrier : float }
  | UpAndIn    of { barrier : float }
  | DownAndIn  of { barrier : float }

type option_product =
  | Vanilla    of { option_type : option_type; exercise : exercise_style }
  | Barrier    of { option_type : option_type; barrier : barrier_type }
  | Asian      of { option_type : option_type; averaging : [`Arithmetic | `Geometric] }
  | Lookback   of { option_type : option_type }

let describe_product = function
  | Vanilla { option_type = Call; exercise = European } -> "European call"
  | Vanilla { option_type = Put;  exercise = European } -> "European put"
  | Vanilla { exercise = American; _ }                  -> "American option"
  | Barrier { barrier = UpAndOut _; _ }                 -> "Up-and-out barrier"
  | Asian   { averaging = `Arithmetic; _ }              -> "Arithmetic Asian"
  | _ -> "Exotic option"

The compiler will warn if we add a new product type and forget to handle it in describe_product. This exhaustiveness checking is invaluable when maintaining a large derivatives library.

1.4 Performance Characteristics

OCaml compiles to native code via an optimising compiler that produces output competitive with C in many benchmarks. For quant finance, relevant performance properties include:

1.4.1 Allocation and GC

OCaml uses a generational garbage collector with:

• A minor heap for short-lived objects (default 256 KB, tunable)
• A major heap for long-lived objects
• Incremental major collection to avoid long pauses

For Monte Carlo simulation — which allocates many short-lived path arrays — the minor GC handles collection extremely cheaply. A 1M-path Monte Carlo engine written naively in OCaml will not pause for GC.

With OxCaml (Jane Street's OCaml extensions), stack allocation eliminates GC entirely for many numerical objects:

(* In OxCaml: 'local_' allocates on stack, not heap *)
let price_path ~steps ~dt ~vol ~rate ~s0 =
  let path = local_ Array.make steps s0 in
  (* ... fill path ... *)
  path.(steps - 1)  (* return only the terminal value *)
  (* path array is freed when function returns, no GC needed *)

1.4.2 Benchmark Comparison

Typical performance ratios for financial calculations (lower is better, C++ = 1.0x):

OCaml's scalar performance is close to C++ without SIMD. With OxCaml's SIMD types (Chapter 30), OCaml can match or exceed hand-tuned C++ for vectorisable workloads.

1.5 The OCaml Ecosystem for Finance

1.5.1 Core Libraries

Jane Street's Core/Base: A comprehensive alternative to the OCaml standard library. Production-tested in a major quantitative trading firm. Provides containers, dates/times, formatting, and more.

open Core

(* Dates *)
let settlement = Date.create_exn ~y:2025 ~m:Month.Jun ~d:15
let expiry = Date.add_business_days settlement ~n:90

(* Typed maps for instrument data *)
let pricer_cache : (string, float) Hashtbl.t = Hashtbl.create (module String)

Owl: Numerical computing for OCaml. Dense and sparse matrices, BLAS/LAPACK bindings, statistical functions, plotting.

open Owl

(* Matrix operations for factor models *)
let factor_returns = Mat.of_array [|0.01; 0.02; -0.01; 0.03|] 1 4
let factor_loadings = Mat.of_array [|0.5; 0.3; 0.8; 0.2;
                                      0.4; 0.6; 0.1; 0.9|] 2 4
let portfolio_exposure = Mat.dot factor_loadings (Mat.transpose factor_returns)

Zarith: Arbitrary-precision arithmetic. Essential for exact decimal calculations in accounting and clearing.

open Zarith.Q  (* Rationals — no floating-point rounding *)

let rate = of_string "3/1000"   (* exactly 0.003 *)
let notional = of_string "10000000"
let coupon = mul notional rate  (* exactly 30000, no rounding error *)

menhir / angstrom: Parser combinators for FIX protocol messages, market data feeds, term sheet parsing.

1.5.2 Build System

OCaml projects use Dune, a composable build system designed by Jane Street:

; dune file for a pricing library
(library
 (name qf_pricing)
 (libraries core owl zarith)
 (preprocess (pps ppx_deriving.show ppx_compare)))

(executable
 (name main)
 (libraries qf_pricing core))

; dune-project
(lang dune 3.10)
(name quantitative-finance)

1.6 Setting Up the Environment

1.6.1 Install opam and OCaml

# Install opam (OCaml package manager)
bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh)"

# Initialize and create a switch with OCaml 5.2
opam init
opam switch create 5.2.0

# Install essential packages
opam install dune core base owl zarith ppx_deriving menhir angstrom

1.6.2 VS Code Setup

Install the OCaml Platform extension. It provides:

• Type-on-hover via ocamllsp
• Inline error highlighting
• Auto-formatting via ocamlformat
• Jump-to-definition across libraries

opam install ocaml-lsp-server ocamlformat

1.6.3 Project Template

mkdir qf_project && cd qf_project
dune init project qf_project --libs core,owl

1.7 A First Program: Compound Interest Calculator

Let us build a compound interest calculator that demonstrates OCaml's strengths: type safety, expressiveness, and correctness.

Specification:

• Support annual, semi-annual, quarterly, monthly, daily, and continuous compounding
• Handle both fixed and variable rate paths
• Return exact decimal results using rational arithmetic

(* file: compound_interest.ml *)
open Core

(** Compounding frequency *)
type compounding =
  | Annual
  | SemiAnnual
  | Quarterly
  | Monthly
  | Daily
  | Continuous
[@@deriving show, compare]

(** Number of compounding periods per year *)
let periods_per_year = function
  | Annual     -> 1
  | SemiAnnual -> 2
  | Quarterly  -> 4
  | Monthly    -> 12
  | Daily      -> 365
  | Continuous -> failwith "continuous: use separate formula"

(** 
    Future value with discrete compounding
    FV = PV * (1 + r/n)^(n*t)
    where n = periods per year, t = years 
*)
let future_value_discrete ~pv ~(rate : float) ~years ~compounding =
  match compounding with
  | Continuous -> pv *. Float.exp (rate *. years)
  | c ->
    let n = float_of_int (periods_per_year c) in
    pv *. (1.0 +. rate /. n) ** (n *. years)

(** 
    Effective annual rate from nominal rate
    EAR = (1 + r/n)^n - 1
*)
let effective_annual_rate ~nominal_rate ~compounding =
  match compounding with
  | Continuous -> Float.exp nominal_rate -. 1.0
  | c ->
    let n = float_of_int (periods_per_year c) in
    (1.0 +. nominal_rate /. n) ** n -. 1.0

(**
    Present value (discounting)
    PV = FV / (1 + r/n)^(n*t)
*)
let present_value ~fv ~rate ~years ~compounding =
  let fv_factor =
    match compounding with
    | Continuous -> Float.exp (rate *. years)
    | c ->
      let n = float_of_int (periods_per_year c) in
      (1.0 +. rate /. n) ** (n *. years)
  in
  fv /. fv_factor

(** 
    Rule of 72: approximate years to double
    t ≈ 72 / (rate_in_percent)
*)
let rule_of_72 ~rate_percent = 72.0 /. rate_percent

(** Pretty-print compounding frequency *)
let pp_compounding = function
  | Annual     -> "annual"
  | SemiAnnual -> "semi-annual"
  | Quarterly  -> "quarterly"
  | Monthly    -> "monthly"
  | Daily      -> "daily"
  | Continuous -> "continuous"

let () =
  let pv = 10_000.0 in
  let rate = 0.05 in
  let years = 10.0 in
  Printf.printf "Principal: $%.2f, Rate: %.1f%%, Term: %.0f years\n\n"
    pv (rate *. 100.0) years;
  Printf.printf "%-20s %-18s %-10s\n" "Compounding" "Future Value" "EAR";
  Printf.printf "%s\n" (String.make 50 '-');
  List.iter [Annual; SemiAnnual; Quarterly; Monthly; Daily; Continuous] ~f:(fun c ->
    let fv = future_value_discrete ~pv ~rate ~years ~compounding:c in
    let ear = effective_annual_rate ~nominal_rate:rate ~compounding:c in
    Printf.printf "%-20s $%-17.2f %.4f%%\n"
      (pp_compounding c) fv (ear *. 100.0)
  );
  Printf.printf "\nRule of 72: %.1f years to double at 5%%\n"
    (rule_of_72 ~rate_percent:5.0)

Running this produces:

Principal: $10000.00, Rate: 5.0%, Term: 10 years

Compounding          Future Value       EAR
--------------------------------------------------
annual               $16288.95         5.0000%
semi-annual          $16436.19         5.0625%
quarterly            $16510.18         5.0945%
monthly              $16534.18         5.1162%
daily                $16486.65         5.1267%
continuous           $16487.21         5.1271%

Notice how increasing compounding frequency approaches the continuous limit. This is a fundamental result in financial mathematics: continuous compounding is the natural limit.

1.8 OCaml vs Other Languages: A Practical Comparison

Correctness

Performance

Expressiveness

1.9 Why Jane Street Uses OCaml

Jane Street is one of the world's largest quantitative trading firms and one of the largest institutional users of OCaml. Their reasons, articulated in numerous public talks and papers, map exactly onto the finance-specific arguments in this chapter:

1. Refactoring confidence: OCaml's type system means that when you change a data structure, the compiler tells you everywhere the code needs to change. In a trading system with millions of lines of code, this is critical.

2. Enforced invariants: Phantom types, abstract types, and module signatures can enforce business rules at compile time. A trade that cannot be submitted without a valid risk limit check, enforced by the type system.

3. Performance without heroics: OCaml's native compiler produces fast code without the complexity of C++ templates and manual memory management.

4. Principled concurrency: With OCaml 5's effect system, concurrent code can be written in a direct style without callback hell or monad transformers.

1.10 Chapter Summary

OCaml's place in quantitative finance is earned, not arbitrary. The combination of static typing with inference, algebraic data types, pattern matching, and native-code compilation addresses the actual problems that arise in financial software: incorrect handling of optional values, non-exhaustive case analysis over instrument types, subtle floating-point errors, and performance on numerical computations.

The comparison with Python is instructive. Python's dominance in research stems from its interactive workflow, rich data science ecosystem (NumPy, pandas, scikit-learn), and low barrier to entry. But research prototypes that work in Python often fail when deployed to production: type errors that the interpreter would have caught crash during live trading, performance is inadequate for real-time computation, and lack of type annotations makes large codebases difficult to maintain and refactor safely. OCaml solves all three problems without sacrificing the expressiveness that makes Python productive.

The comparison with C++ is also instructive. C++ provides the performance that OCaml achieves, but at the cost of manual memory management, undefined behaviour, and a type system that is powerful but notoriously complex. OCaml's garbage collector eliminates the largest source of C++ production bugs (use-after-free, buffer overflows) while achieving comparable performance for numerical workloads. The OCaml native code compiler produces single-pass native binaries with performance that typically benchmarks within 2-3x of hand-optimised C++.

The Jane Street ecosystem — Core, Base, Async, Owl — provides production-grade infrastructure for every layer of a quantitative system: dates and times, collections, concurrent I/O, and numerical computation. OCaml 5's multi-domain parallelism and the OxCaml extensions for stack allocation and mode analysis now bring genuine parallelism and low-latency allocation control to the OCaml programmer.

Exercises

1.1 Modify the compound interest calculator to also compute continuously compounded rate equivalent to a given discrete rate and frequency. That is, find $r_c$ such that $e^{r_c \cdot t} = (1 + r/n)^{nt}$.

1.2 Add a function doubling_time ~rate ~compounding that returns the exact number of years for a principal to double. Use Float.log and validate against the Rule of 72.

1.3 Using phantom types, implement a Rate type that is tagged with its basis convention (Act360, Act365, Thirty360) and write a convert_basis function. The compiler should prevent using a rate with the wrong convention.

1.4 Benchmark OCaml vs a Python equivalent: write a function that computes 10,000,000 Black-Scholes prices (use the formula from Chapter 10 once you reach it, or look it up) and compare wall-clock time.

Next: Chapter 2 — OCaml Essentials for Finance