Return · Apr 2026 · 4 min
An SPV Is a Data Structure
An SPV is a data structure. Treat it like one.
Strip away the legal wrapper and a special-purpose vehicle is a small, well-typed database. A cap table is a join. A capital call is a write. A distribution waterfall is a function that takes proceeds and returns allocations, deterministically, every time. The lawyers give you prose. Underneath the prose is a schema, and the schema is the thing that actually governs who gets paid what.
Treat it as prose and it stays slow and error-prone. Someone maintains the cap table in a spreadsheet, side letters live in an inbox, and the waterfall is re-derived by hand under deadline pressure at the exact moment — the exit — when getting it wrong is most expensive. Every one of those steps is a place for a fat finger to become a wire to the wrong LP.
Treat it as data and the whole vehicle becomes computable. Formation documents generate from a structured template — I have watched a clean SPV's filing package assemble in 47 seconds, not because the drafting was rushed but because the inputs were typed and the output was rendered. The cap table becomes a source of truth a machine can validate: allocations sum to one, side-letter terms resolve without collision, the waterfall runs as code and returns the same answer on the first close and the final distribution.
This is the discipline the RETURN work runs on. Not managing anyone's money — advising on how the vehicle is structured, and structuring it so the structure is legible to a computer. A waterfall you can execute is a waterfall you can audit. A cap table with a schema is a cap table that cannot silently drift. The rigor an institution buys with a back office, you get from treating the thing as what it already is.
An SPV is a data structure. The paperwork is just its serialization. Build it that way from the first close and the exit takes care of itself.