Kumu / Finance & Securities / Stage 4
Stage 4 — Market Data + Population
data/…-market-data.md + re-committed workbook
Replace your placeholders with live market data, document exactly where every number came from, and confirm the model survives contact with reality. Your workbook stops being a classroom exercise and becomes a dated, sourced, defensible analysis.
What you'll learn
- Data operations: retrieving, choosing, and documenting provenance for every market input
- How to compute a CIP-implied forward when no live forward quote is available
- Why "the model broke when real data loaded" means the structure was wrong — and why finding that is the exercise, not a penalty
Your numbers will be unique — on purpose
Everyone retrieves data on their own date, so every student's results differ. Yours will not match anyone else's, and they aren't supposed to.
Retrieve — as of market close on the day you begin
| Input | Source guidance |
|---|---|
S0_in — EURUSD spot | Any reputable quote source — record source + timestamp. |
R_USD, R_FC — 1-year rates | A 1-year government yield or deposit/reference rate per currency. Document which rate you chose and why — the choice matters more than the decimals. |
F0_in — 1-year forward | Use a live forward quote if you can find one; otherwise compute the CIP-implied forward (below) and say so. Compare to your scenario's indicative forward and comment on the gap. |
K_PUT, K_CALL — strikes | Set at or near your live spot, per the scenario convention. |
PREM_PUT, PREM_CALL | Keep the scenario-given premiums (retail-accessible option quotes are unreliable); note this explicitly as an assumption. |
FC_AMT, T_DAYS | From your scenario. |
Where to actually get these numbers
Any reputable source is acceptable — what's graded (50% of this stage) is that every number carries source + timestamp + any proxy logic, not which site you pulled it from. A short guide:
| Tier | Sources | Notes |
|---|---|---|
| Professional terminals the gold standard | Bloomberg · Refinitiv (Eikon / Workspace) | If you have access — the Shidler lab terminals, or a future employer's desk. Carry the live forwards and option quotes free sources often don't. Record the terminal and the timestamp. |
| Free & sufficient for this project | Yahoo Finance · investing.com · ECB reference rates · FRED | Yahoo — EURUSD spot, some forwards. investing.com — spot, forwards, rate instruments. ECB — the daily EURUSD reference fix. FRED (St. Louis Fed) — USD deposit / SOFR-family rates for R_USD. |
The CIP-implied forward
F0 = S0 × (1 + R_USD × T/360) / (1 + R_FC × T/360)This is covered interest parity run forward: the no-arbitrage rate at which a bank could quote
you a forward given the two money-market rates. Using it isn't a shortcut — it's how forwards are
priced. Just say in the memo that F0_in is CIP-implied from your spot and rates.
Then: memo → populate → re-check → cross-check
- Write the market-data memo — a table of every input with value, source, retrieval timestamp, and any proxy or computation used (CIP-implied forward, rate choice). This is a provenance document: an auditor should be able to re-pull every number.
- Populate the workbook — enter the live values into the named-range input cells. Nothing else should need to change. If a formula breaks or an output stops making sense, the structure was wrong: fix it and record what you fixed. Documented fixes are not penalized — finding them is the exercise.
- Re-run the checks — parity passes with live data; the sensitivity table and chart recalculate around the new spot.
- Cross-check against the FX Hedging Lab — enter your live inputs and compare its forward / money-market / option outputs to your workbook. If they disagree, one of them is wrong — find out which before submitting, and record the resolution in the memo.
Submission checklist
- Every input retrieved with source + timestamp recorded
- Rate choices (
R_USD,R_FC) documented with a one-line rationale F0_inis a live quote, or CIP-implied with the computation shown and the gap vs. the indicative forward discussed- Scenario premiums kept and noted explicitly as an assumption
- Live values entered through the named-range input cells only
- Any structural fixes documented honestly in the memo
- Parity check passes with live data; sensitivity recalculates around the new spot
- FX Lab cross-check performed; discrepancies resolved and recorded
- Memo at
data/YYYY-MM-DD-{lastname}-market-data.md; workbook re-committed (message notes the population + fixes) prompt-log.mdupdated if AI assisted the data hunt
Rubric
| Criterion | Weight | Strong work looks like |
|---|---|---|
| Data quality & provenance | 50% | Every input sourced, timestamped, proxies documented; sensible rate choices |
| Model resolves cleanly | 33% | Live data loads through named ranges; checks pass; fixes (if any) documented honestly |
| Lab cross-check | 17% | Comparison performed and documented; discrepancies resolved |
When the professor sends you a pull request
From this stage on, feedback often arrives as a pull request (PR) pushed to your repo — a proposed set of changes shown as a line-by-line diff, with comments attached to specific lines. This is exactly how real code and analyst review works: a reviewer doesn't email you a list of notes, they show you the edit. You are not obligated to accept it blindly — you have real options:
| Option | What it means |
|---|---|
| 1 · Read the diff | The PR is the feedback. Every changed line is a comment on your work — read it before doing anything else. |
| 2 · Merge it | Agree? Click Merge and the changes become part of your repo. |
| 3 · Edit further | Merge, then keep working on top — or commit your own version of the change instead. The PR is a starting point, not a verdict. |
| 4 · Point an LLM at it | Give the PR URL (or the git diff) to Claude or ChatGPT and ask it to apply the revisions, explain why each was suggested, or extend them. |
| 5 · Push back | Reply on the PR explaining why your original is right. Disagreeing with a reviewer — with reasons — is a professional skill, and it's explicitly welcome here. |
The disagreement is allowed to be the point
A reviewer who's always right and a student who always merges both learn nothing. A reasoned push-back beats a reflexive merge — what matters is the quality of your response, not whether you accepted every line.