p14_us_treasury_yield_curve_construction_and_model_comparison

p14_us_treasury_yield_curve_construction_and_model_comparison#

Last updated: Mar 11, 2026, 12:32:50 AM

Table of Contents#

Notebooks 📖

Pipeline Charts 📈

Pipeline Dataframes 📊

Pipeline Specs#

Pipeline Name

p14_us_treasury_yield_curve_construction_and_model_comparison

Pipeline ID

P1

Lead Pipeline Developer

Phoebe Fingold, Annie Reynolds

Contributors

Phoebe Fingold, Annie Reynolds

Git Repo URL

Pipeline Web Page

Pipeline Web Page

Date of Last Code Update

2026-03-11 00:04:57

OS Compatibility

Linked Dataframes

P1:crsp_treasury_daily_prices
P1:crsp_treasury_issue_info
P1:crsp_treasury_consolidated
P1:fed_yield_curve_all
P1:fed_yield_curve

About this project#

This project studies how the U.S. Treasury yield curve is constructed and how different modeling choices affect its shape and interpretation.

High Level Summary of Our Project: The U.S. Treasury Yield Curve: Construction and Model Comparison#

This project studies how the U.S. Treasury yield curve is constructed and how different modeling choices affect its shape and interpretation. We were given working code that reproduces the Gurkaynak-Sack-Wright (GSW) zero-coupon Treasury yield curve, which is widely used in academic and policy work. The GSW curve is based on the Nelson-Siegel-Svensson parametric framework. Our main task in this project is to extend the provided code by estimating and comparing alternative yield-curve methodologies that use interpolation rather than parameterization, as surveyed in Waggoner (1997), including spline-based and arbitrage-free approaches used by central banks. In particular, we seek to replicate the McCulloch (regression splines) and Fisher & VRP (smoothed spline with roughness penalty) approaches outlined by Waggoner. Following a successful replication of these approaches, we compare models in terms of in-sample and out-of-sample fits, smoothness, and behavior across maturities.

This chartbook page provides a further look into the visuals and charts we created to understand the data, how the various replication methods behaved over time, and how they varied on days with low, median, and high correlation.

Quick Start#

The quickest way to run code in this repo is to use the following steps.

You must have TexLive (or another LaTeX distribution) installed on your computer and available in your path. You can do this by downloading and installing it from here (windows and mac installers).

First, create a virtual environment and activate it:

python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

Then install the dependencies:

pip install -r requirements.txt

Finally, run the project tasks:

doit

And that’s it!

Other commands#

Unit Tests and Doc Tests#

You can run the unit test, including doctests, with the following command:

pytest --doctest-modules

You can build the documentation with:

rm ./src/.pytest_cache/README.md
jupyter-book build -W ./

Use del instead of rm on Windows

Setting Environment Variables#

You can export your environment variables from your .env files like so, if you wish. This can be done easily in a Linux or Mac terminal with the following command:

set -a  # automatically export all variables
source .env
set +a

On Windows (PowerShell):

Get-Content .env | ForEach-Object { if ($_ -match '^([^=]+)=(.*)$') { [Environment]::SetEnvironmentVariable($matches[1], $matches[2], 'Process') } }

Formatting#

This project uses Ruff for linting and formatting Python code.

# Auto-fix linting issues (e.g., unused imports, undefined names)
ruff check . --fix

# Format code (consistent style, spacing, line length)
ruff format .

# Sort imports, then fix linting issues, then format
ruff format . && ruff check --select I --fix . && ruff check --fix .

  • ruff check --fix applies safe auto-fixes for linting violations

  • ruff format formats code similar to Black

  • --select I targets only import sorting rules (isort-compatible)

General Directory Structure#

  • The assets folder is used for things like hand-drawn figures or other pictures that were not generated from code. These things cannot be easily recreated if they are deleted.

  • The _output folder, on the other hand, contains dataframes and figures that are generated from code. The entire folder should be able to be deleted, because the code can be run again, which would again generate all of the contents.

  • The data_manual is for data that cannot be easily recreated. This data should be version controlled. Anything in the _data folder or in the _output folder should be able to be recreated by running the code and can safely be deleted.

  • I’m using the doit Python module as a task runner. It works like make and the associated Makefiles. To rerun the code, install doit (https://pydoit.org/) and execute the command doit from the src directory. Note that doit is very flexible and can be used to run code commands from the command prompt, thus making it suitable for projects that use scripts written in multiple different programming languages.

  • I’m using the .env file as a container for absolute paths that are private to each collaborator in the project. You can also use it for private credentials, if needed. It should not be tracked in Git.

Data and Output Storage#

I’ll often use a separate folder for storing data. Any data in the data folder can be deleted and recreated by rerunning the PyDoit command (the pulls are in the dodo.py file). Any data that cannot be automatically recreated should be stored in the “data_manual” folder. Because of the risk of manually-created data getting changed or lost, I prefer to keep it under version control if I can. Thus, data in the “_data” folder is excluded from Git (see the .gitignore file), while the “data_manual” folder is tracked by Git.

Output is stored in the “_output” directory. This includes dataframes, charts, and rendered notebooks. When the output is small enough, I’ll keep this under version control. I like this because I can keep track of how dataframes change as my analysis progresses, for example.

Of course, the _data directory and _output directory can be kept elsewhere on the machine. To make this easy, I always include the ability to customize these locations by defining the path to these directories in environment variables, which I intend to be defined in the .env file, though they can also simply be defined on the command line or elsewhere. The settings.py is responsible for loading these environment variables and doing some preprocessing on them. The settings.py file is the entry point for all other scripts to these definitions. That is, all code that references these variables and others are loaded by importing config.

Naming Conventions#

  • pull_ vs load_: Files or functions that pull data from an external data source are prepended with “pull_”, as in “pull_fred.py”. Functions that load data that has been cached in the “data” folder are prepended with “load”. For example, inside of the pull_CRSP_Compustat.py file there is both a pull_compustat function and a load_compustat function. The first pulls from the web, whereas the other loads cached data from the “_data” directory.

Dependencies and Virtual Environments#

Working with pip requirements#

This project uses pip with a virtual environment. Install requirements with:

pip install -r requirements.txt

To update the requirements file after adding new packages:

pip freeze > requirements.txt
Contents