Intex Client

The question

Structured bonds are among the most intricate instruments on the market. Each deal is a small legal machine, with pools of loans, layered tranches, and rules for exactly who is paid what, and when. Intex is the platform the industry relies on to model them, but it was built for analysts working one deal at a time, by hand.

The team wanted to ask more questions, about more deals, faster.

The approach

I built a client directly on Intex’s C subroutines, the library interface to its modelling engine, so the team can drive Intex from code instead of by hand. It covers the whole workflow, including loading deals, setting up scenarios and assumptions, running cash-flow projections, and returning clean, standardised results that the rest of the team’s analytics can use directly in Pandas and Polars.

Calling the platform was the easy part. Making it understandable and friendly took most of the effort. There are thousands of keywords, more than any single developer could memorise. I built a comprehensive type system using Python enums, so configuring scenarios now comes with autocomplete and consistent names that map to real Intex keywords.

Speed

Once the workflow was automated, speed became the next problem. Deals now run in parallel across many threads, and getting that right took more coffee than you can imagine. Each run has to stay isolated from its neighbours, and a failure in one must never corrupt another. The subroutine library silently stores hidden state, which makes isolation especially important.

Testing

The test suite reflects the sheer size of this library: over 3,000 tests cover AST parsers for Intex-specific languages, real model outputs matched against golden datasets, and all the data structures in between.