Repo-Market Pressure Model

Banks, funds and corporate treasuries borrow cash overnight against U.S. Treasury bonds. On a few days — September 2019, March 2020 — that borrowing suddenly became expensive. The people exposed to those days do not need a better guess at tomorrow’s rate. They need to know how bad tomorrow could plausibly be, and whether that warning can be trusted.

• A model can be right on average and still leave you under-prepared on the day that matters. The question to ask of any risk forecast is how often its worst plausible case is actually exceeded — and the honest answer can be that it is not yet fit to warn.
• A test only counts if it is fixed before the answer is known. The final test’s design was written down and frozen before the locked 2026 days were opened, and the one change made to it was ruled on before the opening, not after.
• Funding spikes appear to come from the calendar and the plumbing — tax dates, Treasury settlement days, quarter-ends, banks’ cash running close to the minimum they need — more than from recent market mood. Published research on September 2019 points the same way, and that is where the current phase goes: estimating how much of the banking system’s cash is really free to lend.
• Checking calibration is a governance duty as much as a statistical one. It is the question a model-risk reviewer exists to ask, and this project is built so that the answer is on the record.

The code is written by AI coding agents working inside rules I wrote. A contract says what each change may touch and which files are reserved for people, and automatic checks fail any change that crosses those lines. The agents run unattended, overnight included, as scheduled cloud sessions — and they are built to stop and ask rather than guess.

Review is delegated, in writing. A separate reviewer session — never the one that wrote the change — checks each pull request against its acceptance criteria and the test suite, merges it, and escalates the cases the rules list to me. I set the direction and make the rulings; I do not read every line, and the repository says which merges were mine.

Because the agents post under my account, a comment there does not prove I wrote it. After an agent once relayed a go-ahead I had not given, a pull request that opens locked test data, or changes the live record’s pinned code or the models it logs, must now cite an approval that a CI check confirms I posted myself. This is the problem AI governance faces inside firms — delegation with accountability, audit trails, separation of duties — practised end to end on a real project.

Work runs as directives: short written issues saying what to build, what must not change and how the result will be checked. Each is taken by one AI session as one pull request, and nothing reaches the main line until the full test suite passes. My rulings are kept in the repository as decision records that later work must follow.

The completed work establishes a reproducible data and forecasting foundation; the phases below are research extensions, not prerequisites to reading the findings above as a model-risk case study. A phase ends when it meets a written exit test or, where the evidence is incomplete, by a recorded decision that lists what stays open — which is how the dataset and forecasting phases were closed. The status above is generated from the project’s own plan rather than typed here.

• Phase 0 — Foundations: every result can be rebuilt from a clean copy of the code and the data.
• Phase 1 — The dataset: public U.S. funding-market data — Federal Reserve rates and balances, Treasury settlements and bill rates, dealer positions — each stamped with the moment it became public.
• Phase 2 — Forecasting: a model that beats the simple forecast and stays honest about the bad days.
• Phase 3 — Hidden cash: estimating how much of the banking system’s cash is really free to lend once the buffer banks want to keep is set aside — something nobody publishes directly. This work runs in a companion repository, repo-market-liquidity.
• Phase 4 — Supply and demand: who lends, who borrows, and where the price settles.
• Phases 5 to 7 — Research directions: filling data gaps and mapping the links between institutions, a stress-testing engine, and a European version.

• Target: the next-business-day predictive distribution of the SOFR–IORB spread in basis points, as five published quantiles, and the probability that the spread closes strictly above +5 and +10 bp, from each input’s latest value public at 16:00 ET on the previous business day. Days above +20 and +50 bp are listed event by event rather than pooled.
• Data: a versioned point-in-time panel from New York Fed reference rates (SOFR with its percentiles and volume, TGCR, BGCR) and primary-dealer positions, Federal Reserve administered rates and balances (IORB, checked against ALFRED vintages; reserves; the Treasury General Account), Treasury bill rates and settlement data, and calendar columns. Snapshots are immutable and checksummed; every field carries its availability time and release lag; missing values, structural zeros and unavailable cross-sections stay distinct. Series whose history is restated after the fact are refused by the build until their value on the day can be shown.
• Information rule: each input is read at its latest value public at the decision instant, field by field, with leakage and staleness guards both required to hold. It replaced a derived purge that had left the earlier forecasts about a week stale; those records are archived.
• Evaluation: as-of rolling-origin backtesting on an expanding window, refitted every 21 scored days on one shared fold grid. September 2019 and March 2020 are frozen as checksummed event windows and scored like other days. Days from 2026 were held back from every comparison until a pre-registered final test opened them once; a live record logs a forecast each business day from pinned code, under a scoring declaration written before any outcome exists.
• Models: a persistence benchmark, ARX, SETAR threshold regression, rolling-residual intervals, and gradient-boosted quantile regression. The published distribution is calibrated by conformal PID with nested walk-forward selection of its constants, after split-conformal and cross-conformal (CV+) were scored. The pressure probability is read from that distribution and recalibrated out of fold, at one to five days ahead.
• Scoring: the five-quantile score (mean pinball loss over the published quantiles) and interval coverage; Brier score, Brier skill and CORP reliability at each threshold; paired differences against as-of persistence, a calendar-type climatology and a persistence-logistic model, with stationary-bootstrap intervals, split by regime and by type of day. Where a forecast gave probability zero to an event that happened, the log score is reported as missing rather than clipped.
• Guards: a leakage test changes every post-forecast observation, refits, and requires a bit-identical forecast; mutation tests prove that each guard fires; every published figure is regenerated from a run record naming its commit and data digest; and a change that opens locked test data or alters the live record must cite an approval that CI confirms the owner posted herself.
• Stack: a standard-library Python core with no runtime dependencies; the machine-learning model sits behind an optional ml extra (numpy and scikit-learn) and records the library versions it was fitted with.