Kumu / Finance & Securities / Stage 4
Stage 4 — Market Data + Population
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.
Objective
- 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.
Do — 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 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 (a campus lab terminal, 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.
Do — 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, so find out which before submitting, and record the resolution in the memo.
Deliverable
| What | Where it goes |
|---|---|
| The market-data memo | data/YYYY-MM-DD-{scenario}-market-data-memo.md |
| The populated workbook, re-committed | capabilities/fx-hedging/model.xlsx |
- 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-{scenario}-market-data-memo.md; workbook re-committed (message notes the population + fixes) prompt-log.mdupdated if AI assisted the data hunt
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.