Introduction to Financial Engineering

Introduction

You're hiring or learning for a role that must price and hedge complex trades, so here's the short map: Financial engineering means using math, statistics, and code to build pricing and risk tools - models that turn market moves into dollar outcomes. Its scope covers derivatives pricing, risk management, portfolio construction, and structured products, each demanding different models and data but sharing the same toolbox. To get productive you need the basics: calculus (multivariable), probability, linear algebra, and a production language like Python or C++; start with a 12-week plan that mixes theory and coding so you can build a pricing prototype in weeks, not months - defintely start with Python notebooks and a small options-pricing project. You: enroll in a course and build a first model this month.

Key Takeaways

• Financial engineering = math + statistics + code to turn market moves into dollar outcomes (pricing, hedging, risk, structured products).
• Prerequisites: multivariable calculus, probability, linear algebra, and a production language (Python or C++).
• Core models/techniques: stochastic processes (BM, GBM, mean reversion), risk‑neutral pricing/martingales, Black‑Scholes, Monte Carlo, PDEs, and calibration to implied vol surfaces.
• Risk & production essentials: measure market risk (VaR/ES), manage counterparty risk (CVA/DVA), validate models, and handle data, latency, scaling, and reproducibility.
• Practical roadmap: follow a 12‑week applied plan, build a Monte Carlo pricer and hedge a European call, then deliver one applied project per month to progress to production readiness.

Core concepts

You're building the foundation for pricing and risk work; start with a few core probabilistic and market constructs and you'll cut months off trial and error. Quick takeaway: master Brownian motion and mean reversion, price by discounting expectations under the risk-neutral measure, and know how options, futures, swaps, and CDS pay and hedge.

Stochastic processes

Stochastic processes model asset paths. Learn three staples: Brownian motion (continuous random walk), Geometric Brownian Motion (GBM, log‑normal returns), and mean reversion (Ornstein‑Uhlenbeck for rates/vols). GBM formula is S_t = S_0 exp((mu - 0.5 sigma^2)t + sigma W_t). For a quick check use S_0 = 100, mu = 5%, sigma = 20%: E[S_1yr] ≈ 100 e^{0.05} = 105.13. What this hides: real drift differs from risk‑neutral drift (use r when pricing).

Practical steps:

• Simulate with Euler‑Maruyama, dt = 1/252 for daily
• Use 10,000+ paths for stable Monte Carlo estimates
• Apply antithetic variates and control variates to cut error
• Seed RNG and save paths for reproducibility and debugging

Best practice: validate moments (mean/variance) and sample tails against analytic results before trusting pricing. One clean line: simulate, check mean/var, then price - repeat.

Pricing theory

Direct takeaway: price by discounting expected payoff under the risk‑neutral measure Q, ensuring the model is arbitrage‑free so discounted asset prices are martingales (no predictable gains). In plain terms, pricing = choose model, calibrate to market, compute E^Q[payoff], discount at r: price = e^{-rT} E^Q[payoff].

Steps and checks:

• Choose model (BS/GBM, Heston, jump models) that fits instrument features
• Calibrate to liquid market prices (vanilla options for vol surface)
• Compute expectation analytically when possible; else use Monte Carlo or PDE
• Confirm absence of static arbitrage on implied vol surface
• Backtest prices vs. realized P&L under replication hedges

Quick math example: pricing a 3‑month ATM European call with S=100, K=100, sigma=20%, r=4.0% gives price ≈ $4.43 (Black‑Scholes). What to watch: model risk from wrong vol dynamics and mis‑spec'd tails - validate with out‑of‑sample market moves. One clean line: calibrate, price, hedge, then verify P&L.

Fundamental instruments

Direct takeaway: know each instrument's payoff, daily mechanics, and typical hedges. Options give optional payoffs; futures lock a forward payoff with daily settlement; swaps exchange cashflow streams; credit default swaps (CDS) transfer default risk.

Practical guidance and examples:

• Options: compute Greeks (delta/gamma/vega/theta). Example hedge: one European call with delta = 0.56 - to delta‑neutralize 10 contracts (US: 100 shares/contract) short 560 shares.
• Futures: model as forward price; remember daily mark‑to‑market and margin calls - size initial margin into liquidity plan.
• Swaps: price via PV(fixed leg) = PV(floating leg); treat notional as off‑balance for exposures but on‑balance for credit risk.
• Credit derivatives: CDS spread of 100 bps on $10,000,000 notional implies annual premium ≈ $100,000 (ignoring accruals). Hedge with correlation and recovery assumptions tested.

Best practices: always map instrument payoff to hedgable units, simulate P&L under realistic rebalancing (daily or intraday), and stress test key drivers. One clean line: know payoff, compute sensitivities, then trade the hedge.

Next step: You: implement a GBM Monte Carlo pricer (use 10,000 paths, dt = 1/252) and run a delta‑hedge backtest by Friday; risk or quant should own the backtest and report P&L curves.

Modelling techniques

You're choosing how to price and hedge in production - analytic formulas where they work, numerical methods where they don't, and calibration to match market quotes. Direct takeaway: use Black‑Scholes and closed‑form Greeks for benchmarks and fast Greeks, Monte Carlo or PDEs for path‑dependent or complex payoffs, and calibrate using weighted fits plus an arbitrage‑free surface (SVI or similar).

Analytical methods: Black‑Scholes and closed‑form Greeks

If the payoff fits the Black‑Scholes assumptions (lognormal spot, constant volatility, continuous trading), use the closed form: it's fast, differentiable, and ideal for hedging prototyping.

Practical steps

• Compute price with Black‑Scholes formula for European options.
• Compute Greeks analytically: Delta = N(d1), Gamma = phi(d1)/(S sigma sqrt(T)), Vega = S sqrt(T) phi(d1), Theta and Rho from standard formulae.
• Use the analytic Greeks as control variates when you run Monte Carlo or PDE solvers.

Quick example math for clarity: S=100, K=100, r=0.02, sigma=0.20, T=0.5 years gives price ≈ $6.10, Delta ≈ 0.556, Gamma ≈ 0.0279, Vega ≈ 27.9 (so per 1 percentage point vol change, price changes ≈ 0.279). What this estimate hides: no dividends, constant vol, continuous hedging.

Best practices

• Always report units for Greeks (price per 1% vol, per $1 underlying).
• Flag model assumptions in any desk report; analytic is a yardstick, not gospel.
• Use analytic Greeks for real‑time delta hedging; reprice numerically for model validation.

One clean line: use closed form for speed, but check assumptions first.

Numerical methods: Monte Carlo (10k+ paths) and finite difference PDEs

Monte Carlo (MC) and finite difference (FD) PDEs cover payoffs Black‑Scholes can't: path‑dependence, early exercise with stochastic vol, exotic barriers. Choose MC for high‑dimensional problems and FD for 1D-2D problems where accuracy near boundaries matters.

Monte Carlo: practical guide

• Start with 10,000+ paths for a sanity check; move to 100,000+ for production-grade pricing where standard error matters.
• Use Euler‑Maruyama or Milstein schemes; set time steps so dt ≤ 1/252 for daily or smaller for barrier monitoring.
• Apply variance reduction: antithetic variates, control variates (use analytic price), moment matching, and quasi‑Monte Carlo (Sobol) for smoother convergence.
• Estimate Monte Carlo standard error: stderr ≈ sampleStdDev / sqrt(N). Example: payoff stddev 20 with N=10,000 → stderr ≈ 0.20 (95% CI ≈ ±0.40).
• Parallelize at the path level; fix RNG seeds for reproducibility; persist random states for backtests.

Finite difference (PDE) methods: practical guide

• Discretize S and t; choose Smax = S03-5 (or use log grid) to capture tails.
• Prefer Crank‑Nicolson (implicit, second‑order) for stability and accuracy; use Rannacher smoothing near t=0 for non‑smooth payoffs.
• Set grid: NS ~ 200-800, NT ~ 200-800 depending on accuracy; check convergence by doubling NS/NT.
• Implement boundary conditions carefully: linear payoff at high S, zero at S=0 for calls (or use reflective boundaries for numerical stability).
• Use FD for American exercise (via PSOR or explicit free‑boundary methods) and for local vol calibration where you need the full PDE solution.

Deployment and testing

• Cross‑validate Monte Carlo vs analytic price for vanilla payoffs; use Black‑Scholes as control variate.
• Unit test grid convergence, path convergence, and runtime; automate nightly regression tests.
• Profile hotspots; move inner loops to C++ or GPU if latency matters.

One clean line: Monte Carlo scales to complexity; PDEs give precision near boundaries - use both as complementary tools.

Calibration: parameter estimation and implied volatility surfaces

Calibration maps model parameters to market prices. The goal: fit the market surface tightly while avoiding overfitting and arbitrage. Use implied vols as the target space - they're stable and intuitive.

Concrete calibration steps

• Collect clean market data: top‑of‑book mid prices, trade sizes, and accurate expiry/settlement conventions.
• Convert prices to implied vol (IV) for each strike/expiry; work in log‑moneyness k=ln(K/F) and total variance w=IV^2 T.
• Choose a parameterization: SVI (Stochastic Volatility Inspired) for each expiry or global stochastic local vol models for cross‑expiry consistency.
• Set objective: minimize weighted squared error in price or IV. Weight by liquidity or by vega: weight_i = 1/vega_i^2 reduces bias toward far‑OTM options.
• Optimize: use global search (differential evolution) then local (Levenberg‑Marquardt or BFGS). Enforce constraints to keep surface arbitrage‑free.

Practical numbers and diagnostics

• Target fit errors: IV RMSE ≤ 0.5 implied vol points for liquid markets; per‑strike price residuals within market bid‑ask is ideal.
• Monitor calendar and butterfly arbitrage; impose convexity in strike and monotonicity in expiry.
• Recalibrate intraday for fast markets; nightly full recalibration for production.

What to watch for

• Data issues: stale or crossed quotes produce misleading IV spikes - filter by trade time and size.
• Overfitting: regularize parameters and prefer parsimonious models; track out‑of‑sample error.
• Parameter stability: large day‑to‑day jumps indicate model mismatch or data problems.

One clean line: calibrate to IV space, weight by vega, and enforce arbitrage constraints to get a usable surface - defintely automate checks.

Risk measurement and controls

You're responsible for keeping trading losses, counterparty hits, and model failures within limits; prioritize daily market-risk monitoring (VaR/ES), integrated CVA/DVA for counterparty exposure, and a strict model-validation program so surprises stay small and explainable.

Market risk: VaR (historical/simulation) and Expected Shortfall

Measure losses using both Value at Risk (VaR) and Expected Shortfall (ES) because VaR tells you a threshold and ES tells you the average tail loss beyond that threshold. Under current regulatory practice for trading books use ES at 97.5% on a 10-day horizon (FRTB standard). For daily desk ops run a 1-day VaR and scale carefully - square-root-of-time scaling hides fat tails, so prefer direct 10-day scenarios when possible.

Practical steps:

• Run historical VaR (rolling window, e.g., 500 days).
• Run Monte Carlo VaR with at least 10,000 paths for non-linear books.
• Compute ES at 97.5% and report both VaR and ES to desks and risk committee.
• Perform daily P&L attribution (risk-theoretical vs realized) and log exceptions.

Backtesting and escalation: use Kupiec (coverage) and Christoffersen (independence) tests; expect ~5% exceptions at 95% VaR over a long window - more means model or position issues. If exceptions cluster, escalate to trading and model owners within 24 hours.

One clean action: enforce daily VaR/ES runs, immediate P&L explain, and an automated exception ticket if an unexplained breach appears.

Risk owner: Head of Market Risk - publish daily VaR/ES dashboard by 07:00 ET.

Counterparty and credit risk: CVA and DVA basics

CVA (credit valuation adjustment) prices expected counterparty credit loss into trade values; DVA (debt valuation adjustment) prices your own default benefit. You must compute CVA for uncollateralized or partially collateralized exposures and reflect collateral, netting, and wrong-way risk (when exposure rises as counterparty credit quality falls).

How to compute CVA-step by step:

• Generate exposure profile: simulate expected positive exposure (EPE) per future date.
• Obtain default probabilities: use market-implied PDs from CDS or rated-implied curves.
• Apply recovery rate: regulatory common assumption is 40% unless evidence suggests otherwise.
• Discount and integrate: CVA ≈ sum over t of (1 - Recovery) × EPE(t) × PD(t) × discount(t).

Quick math example: if EPE = $10,000,000, annual PD = 2%, recovery = 40%, one-year CVA ≈ (1 - 0.40)×10,000,000×0.02 = $120,000. What this estimate hides: term structure of PDs, collateral timing, and wrong-way risk - always stress those assumptions.

Best practices: refresh PDs daily, mark collateral and thresholds in exposure engine, run CVA VaR for capital planning, and adjust prices or capital for material CVA. For bilateral desks include DVA carefully in P&L governance to avoid mis-incentives.

One clean action: implement a nightly CVA run with market-implied PDs and post a stale-rate flag if CDS liquidity is low.

Risk owner: CVA desk / Counterparty Risk - deliver nightly CVA feed by 03:00 ET.

Model risk: validation, backtesting, governance

Model risk is the loss from using a defective model. Control it with independent validation, systematic backtests, and strict change governance. Treat models as products: owner, spec, tests, and lifecycle. Defintely keep an up-to-date inventory and a challenger model for material components.

Validation and backtesting program:

• Maintain a model inventory listing owner, purpose, materiality, and last validation date.
• Run daily monitoring: input sanity checks, parameter drift alerts, and unit tests in CI.
• Backtest performance: for VaR use Kupiec and Christoffersen tests; for ES use comparative backtesting and proper scoring rules.
• Set quantitative triggers: with a 250-day sample, exceptions of 0-4 are green, 5-9 yellow, 10+ red per Basel traffic-light guidance - escalate on yellow and stop new business on red pending fixes.
• Independent model validation: annual deep review, quarterly spot checks, and independent sign-off before production changes.

Governance and production controls: require code review, version control tags, reproducible builds (containers), fixed RNG seeds for tests, data lineage, and a model-change checklist signed by owner and validator. Keep validation reports concise: assumptions, test results, material weaknesses, and remediation timeline with owners.

One clean action: create an independent validation ticket for each model change and block production merge until signed off.

Risk owner: Model Risk Committee - require validation sign-off before go-live; schedule annual reviews for top 20 models.

Technology and data

You're wiring pricing and risk systems that must run correctly day one and scale through stress events. Focus on three things: get the data right, pick a pragmatic stack (Python for research, C++ for hot paths), and design for low-latency, scalable, reproducible production.

Data needs: tick data, reference data, corporate actions

Tick data captures every trade and quote; reference data holds static mappings (tickers, ISIN/CUSIP/FIGI, exchange codes); corporate actions record splits, dividends, mergers. If any of those are wrong, prices, Greeks, and backtests will be wrong - fast.

Practical steps to get started:

• Capture raw feeds immutably - never overwrite the raw input.
• Timestamp to at least microsecond precision and store timezone info.
• Normalize feeds to a canonical schema (trade/quote/event).
• Store corporate actions as event rows with effective and announced dates.
• Maintain a master reference table that maps instrument IDs across vendors.
• Partition and compress storage by date/instrument (Parquet or columnar format).

Best practices and checks:

• Validate sequence numbers and feed heartbeats on ingest.
• Run daily reconciliation: trades vs exchange official tape.
• Backfill gaps immediately and tag imputed data for downstream users.
• Keep at least 5 years of normalized reference and corporate-action history for backtests and audits.

One-liner: Store raw ticks immutably; derive everything else.

Tech stack: Python/R for research, C++ for low-latency production

Use high-productivity tools for research and high-performance languages for production. Python and R let quants iterate fast; C++ (or Rust) gives predictable, low-latency performance where it matters.

Concrete stack and role separation:

• Research: Jupyter, Python, pandas, NumPy, SciPy, PyTorch for experiments.
• Streaming and integration: Kafka or similar for event buses and durable message queues.
• Storage: Parquet on object storage for cold, ClickHouse/Timescale or kdb for hot analytics.
• Production compute: C++/Rust services for pricing engines, microservices for orchestration.
• Deployment: Docker images + Kubernetes for scaling; CI/CD pipelines for builds and tests.

Actionable migration path for a feature:

• Prototype in Python with a clear API and unit tests.
• Profile hotspots; port critical loops to C++ or use Numba/Cython if latency allows.
• Define binary API/ABI contracts and message schemas before shipping.
• Automate nightly performance regression tests and memory-checks.

One-liner: Prototype in Python, ship critical parts in C++.

Production challenges: latency, scaling, reproducibility

Latency, scale, and reproducibility are the three failure modes you must design around. Latency breaks hedges, scale breaks pipelines, and irreproducible results break audits and P&L attribution.

Practical mitigations and checks:

• Measure latency sources: network, serialization, GC/heap pauses.
• Use binary protocols (flatbuffers/Cap'n Proto) for low overhead messaging.
• Isolate GC languages (Python/Java) from hot paths; use native services for execution.
• Shard by instrument or strategy to scale horizontally; keep partitions aligned with Kafka topics.
• Implement backpressure and bounded queues to avoid cascading failures.
• Provenance: log feed offsets, data snapshot IDs, model commit hashes, and RNG seeds used for pricing.
• Reproducibility tools: containerized runs, MLflow or simple model registries, and daily snapshotting of calibration outputs.
• Governance: automated backtests, daily P&L reconciliation, and model validation signoffs.

Operational playbook (what to automate first):

• Automate feed and reference-data reconciliation (fail on mismatch).
• Run nightly deterministic reruns of pricing for any changed model or data.
• Alert on calibration drift and P&L variances beyond thresholds.

One-liner: If you can't reproduce a P&L, you can't run it.

Immediate next step: Data Engineering capture one month of US-equities tick data into immutable Parquet on object storage and register the snapshot ID as SNAP-2025-12-01 by December 6, 2025 - Owner: Data Engineering.

Career paths and industry fit

Typical roles

You're sizing up which quant role fits you and what each day looks like. Below I map the common roles so you can pick the one that matches your skills and appetite for coding, math, and trading interaction.

Quant researcher - develops models and trading signals; heavy on stochastic calculus, statistics, and prototyping in Python or Matlab. Day tasks: derive model, run simulations, write research note, present to trading desk. Expect to own papers and backtests.

• Core skills: stochastic processes, optimization, statistical inference
• Deliverables: research notebooks, factor/algo backtests

Quant developer - productionizes models with a focus on performance, reliability, and low-latency C++ or Rust code. Day tasks: implement pricing engine, optimize memory, deploy service, triage bugs.

• Core skills: systems programming, profiling, CI/CD
• Deliverables: production library, performance SLAs

Structurer - designs tradable products (structured notes, bespoke derivatives), mixes risk and client constraints, and writes term sheets. Day tasks: price structures, explain payouts to sales, hedge in markets.

• Core skills: pricing intuition, client communication, regulatory awareness
• Deliverables: priced structures, hedging plan

Risk quant - measures and controls risk exposures (market, credit, model), builds VaR/ES pipelines, and produces P&L explain. Day tasks: backtest risk models, run stress tests, report limits.

• Core skills: risk metrics, time series, governance
• Deliverables: risk reports, backtests, limits recommendations

One-liner: choose the role where you enjoy either deep modeling, production craft, client design, or risk governance - not all four.

Hiring signals

You want to know what gets you past the resume screen and into the offer. Hiring panels look for three clear signals: math depth, coding ability, and demonstrable projects.

Math depth: show mastery of probability, SDEs (stochastic differential equations), linear algebra, and optimization. The quickest proof: a short technical writeup that derives a model and walks through assumptions. Interviewers expect you to solve a derivation in 15-30 minutes.

Coding tests: be ready for algorithmic problems plus a practical coding exercise. Benchmarks that stand out:

• Solve 3 algorithmic problems in 45 minutes
• Implement a Monte Carlo pricer (vectorized Python) in 90-120 minutes
• Explain tradeoffs between Python and C++ for latency

Practical projects: recruiters value shipped work. Good portfolio items:

• Monte Carlo pricer with Greeks and hedging backtest
• Small production library with CI and benchmarks
• Research note showing out-of-sample backtest

One-liner: clear math, fast clean code, and two practical projects beat a long list of coursework every time.

Transition examples

You're changing lanes - from PhD to researcher, or developer to production quant. Below are concrete steps, timelines, and what to show.

PhD → quant researcher: translate your thesis into tradable outputs.

• Pick one core idea from your thesis and implement a simulator/backtest (8-12 weeks).
• Write a 6-10 page research note with plots and out-of-sample results.
• Prepare two talk slides and a one-page TL;DR for interviews.

Developer → production quant: prove you can meet trading SLAs and understand models.

• Build a small pricing engine in C++ with Python bindings; include benchmarks (10-16 weeks).
• Show a PnL explain: run a simple strategy, produce daily PnL attribution for 30 days.
• Demonstrate deployed code: Docker, CI, and a performance report.

Quick math: 10 hours/week × 12 weeks = 120 hours - enough to build one solid project and a concise writeup; that portfolio often opens interviews. What this estimate hides: review time and interview prep.

One-liner: pick one project, ship it end-to-end, and be ready to explain every line and assumption.

Next step: You - finish a Monte Carlo pricer with hedging backtest and a one-page research note in 8 weeks; Recruiter/Hiring Manager - review and schedule interviews after you submit.

Introduction to Financial Engineering - immediate action plan

You want to move from theory to a working workflow: implement a Monte Carlo pricer and backtest delta hedges to prove your model works in real markets. The quickest path is a focused 6‑month project with monthly applied tasks, concrete metrics, and reproducible code.

Immediate next steps: implement a Monte Carlo pricer and backtest hedges

Start by building a minimal, verifiable pricer that you can extend. One clean goal: price a European call under Black‑Scholes and a Geometric Brownian Motion (GBM) Monte Carlo, then run a delta‑hedge backtest with daily rebalancing.

Step list - what to build first:

• Implement closed‑form Black‑Scholes for price and Greeks.
• Code GBM Monte Carlo with antithetic variates and control variate option (use Black‑Scholes as control).
• Use 100,000 paths and 252 steps per year as baseline.
• Compute pathwise delta and run daily delta rebalancing simulation.
• Record P&L, hedging error, and transaction costs (start with 5 basis points per trade).

Here's the quick math: 100,000 paths × 252 steps = 25,200,000 forward steps; expect vectorized Python to take minutes, optimized C++/numba much less. What this estimate hides: I/O, random‑seed reproducibility, and calibration overhead.

Best practices and checks:

• Fix RNG seed and log versions for reproducibility.
• Use antithetic and control variates to cut variance by 30-70% (typical).
• Validate Monte Carlo against Black‑Scholes within 0.1% for vanilla calls.
• Backtest over a rolling historical window ending Nov 30, 2025, at least 10 years if available.

Learning roadmap: one applied project per month and core texts

You should learn by doing: one focused project per month keeps momentum and builds a portfolio you can show in interviews. The objective is practical competence, not perfect math proofs.

• Month 1 - Monte Carlo pricer and basic hedging (this project).
• Month 2 - Greeks via pathwise and Likelihood Ratio, implement analytic controls.
• Month 3 - Calibrate implied volatility surface and fit local vol model to market option chains.
• Month 4 - Implement PDE finite‑difference solver and compare to Monte Carlo.
• Month 5 - Build simple CVA pricing example and counterparty exposure simulation.
• Month 6 - End‑to‑end price + hedge a European call live backtest and produce writeup.

Core references to read alongside projects (canonical, practical):

• John C. Hull - Options, Futures and Other Derivatives.
• Paul Glasserman - Monte Carlo Methods in Financial Engineering.
• Steven E. Shreve - Stochastic Calculus for Finance (volumes I & II).
• Brigo & Mercurio - Interest Rate Models (if doing rates/IR derivatives).

Study tips: code first, then read the math for the bits that broke. Keep projects in small repos with tests and a reproducible environment (conda/docker). That makes interview demos defintely stronger.

Practical milestone: price and hedge a European call over 6 months

Define success with measurable deliverables and acceptance criteria. Over 6 months you should produce a reproducible pricer, a hedging backtest, and a short report showing model vs. reality.

• Deliverable 1 (Weeks 1-4): Working Monte Carlo + Black‑Scholes control with unit tests.
• Deliverable 2 (Weeks 5-8): Daily delta hedging engine and transaction cost model implemented.
• Deliverable 3 (Weeks 9-16): Calibrate implied vol surface to option chains; integrate into pricer.
• Deliverable 4 (Weeks 17-20): Backtest over historical window (10 years ending 2025‑11‑30); produce P&L, RMSE of hedging error, and 95% VaR.
• Deliverable 5 (Weeks 21-24): Final report, annotated notebook, and simple REST API for pricing.

Acceptance criteria (quantitative):

• Model price vs. market midpoint within 0.5% on in‑sample instruments.
• Delta‑hedge RMSE reported and benchmarked; present hedging P&L distribution with 95% confidence band.
• Reproducibility: full run in a Docker image with seeds yields identical results.

Operational notes: store raw tick/option chain snapshots, use UTC timestamps, and document corporate actions. If daily rebalancing increases costs beyond expectations, test weekly rebalancing and compare trade counts and P&L impact.

Next step and owner: You: implement the baseline Monte Carlo pricer (use 100,000 paths, 252 steps) and run the first delta‑hedge backtest over a 1‑year historical window ending 2025‑11‑30; deliver a reproducible notebook by Friday and push the repo to your team workspace.