Liquidity-as-code

Readers can check it out here:

Liquidity-as-code (beta)

After writing last week’s Substack post on the benefits of policy as code and sharing a demo of a policy-as-code editor, I wanted to drill down into a specific reg, to see how far one could get converting an entire finreg requirement into code.

I decided to focus on liquidity reporting, specifically, the Fed’s requirement for large banks (FR2052a). This report can be traced back to the 2008 global financial crisis, when authorities were flying blind and a uniform liquidity risk report had to be created from scratch (a scarring and formative experience, I can attest). Since then, the 2052a has become one of the most indispensible reporting requirements for financial stability. In any stress to the system, the 2052a data provides critical intel to a wide range of stakeholders, including principals.

Banks must provide granular data across many fields. The reporting instructions total 253 pages (in PDF, of course). By the Fed’s estimate, it takes banks on average 121-221 hours per response to meet the reporting requirements. GSIBs must file daily. Because there are so many fields and funding markets are so dynamic, it requires constant effort by both banks and regulators to ensure the reporting is robust.

Machine-readability would dramatically reduce the amount of interpretation and translation error and enable direct interaction between banks’ and the Fed’s systems.

So, using Claude Code, I spun up this site.

It contains all of the requirements laid out in the FR2052a instructions and provides a toggle to see them in machine-readable form: markdown with YAML frontmatter, cross referenced to statutory provisions, the Fed’s liquidity risk monitoring definitions, and an open-source LCR calculator (based on Morphir).

In the machine-readable view, one can click on the Cmd-K button, which pulls up a small terminal-looking window and select from a range of tools. These tools are made possible because of the machine-readability of the reg. For instance, the /map tool allows users to type in a funding instrument type and it will pull up in code form the relevant sections that apply, thereby minimizing interpretation/translation error.

I also added an annotation feature that allows users to post questions and feedback on specific provisions. Typically, banks with questions about how to report something engage with their examiners or with DC policy staff, who must operate through a centralized and cumbersome FAQ process, which takes a long time and doesn’t yield much. Questions are bilateral and confidential -- meaning shared issues are buried for long periods of time and lie dormant until they become enough of a problem for a trade group to make noise about. Enabling live questioning and discussion amongst users (banks) would provide regulators and banks with richer feedback much earlier, before problems grow to a point of needing more formal action.

It took 1.5 days for me to complete this project. I did quite a bit of planning with Opus 4.6, then asked it produce precise instructions for the terminal version of Claude Code to execute. My familiarity with the FR2052a report and underlying subject matter was important at several stages to course correct what was being output — i.e., this is not a task that coding agents should do by themselves. Subject matter experts must be involved. The underlying code for the FR2052a machine-readable site is available on GitHub here.

My hope is that this prototype shows the feasibility of policy-as-code generally, and of liquidity-as-code specifically. For those more broadly interested in this topic, I highly recommend checking out The Agentic State and Jennifer Pahlka‘s most recent Substack post on AI in government.

What other financial regulations do folks think would benefit most from being machine readable?