The problem
A deal begins with a pool cut: a file describing the assets being financed, produced by whichever counterparty owns the data, in whatever format their systems emit.
Everything downstream depends on it. Analysts stratify the pool along the dimensions the deal cares about, check the results against the proposed terms, and reproduce the numbers across a term sheet, a credit paper and an investor deck.
Done by hand, that work concentrates in the days before a deal goes out — exactly when the people doing it have the least attention to spare.
A term sheet that disagrees with a credit paper about the same number is discovered by the audience least forgiving of it.
Ingestion: the unglamorous half of the system
Most of the engineering difficulty lives in ingestion, not analytics.
Pool cuts arrive with different column names for the same field, different date and currency conventions, and structural quirks that are obvious to an analyst and invisible to a naive parser. The platform has to normalise arbitrary inputs into one internal representation — and, as importantly, refuse to guess.
A system that silently interprets an ambiguous column has taken a question a human could answer in seconds and turned it into an error nobody notices until it reaches a document.
Surfacing the ambiguity is slower on the first file from a new counterparty and faster on every file afterwards, because the resolution is remembered.
Verification has to be exact, not approximately right
Stratification checks have no tolerance for error. A stratification that disagrees with the deal terms is a problem that surfaces in front of investors.
The verification layer should therefore be deterministic and testable — rules expressed explicitly rather than inferred, results reproducible from the same input every time.
Language models are useful here for drafting narrative sections and interpreting inconsistent inputs. They are unsuitable for anything a regulator, an investor or an auditor might ask you to reproduce exactly. Drawing that boundary explicitly means each part of the system can be tested in the way appropriate to it.
Document generation from a single source of truth
Term sheets, credit papers and investor decks are three presentations of one dataset, aimed at three audiences.
Generating all of them from the verified deal record removes the class of error the manual process can never eliminate: derived documents cannot disagree, because nothing is transcribed.
It also changes what a late correction costs. When a number moves — as numbers do — updating one record regenerates every document consistently, instead of starting a search through three files for the places it appeared.
Work measured in days becomes work measured in minutes, and iterating on deal structure becomes cheap enough to actually do.
Where the pattern applies
The pattern generalises to any business where inconsistent inbound data feeds high-stakes outbound documents.
- Normalise ruthlessly at the boundary.
- Refuse to guess.
- Keep the correctness-critical layer deterministic and testable.
- Derive every document from one verified record.
The part that generalises least is the domain rules themselves. A verification layer is only as good as the understanding of the business encoded in it. That is why the early weeks of a build like this belong with the people who currently do the work, not with the data alone.
Establishing that reasoning is what a Discovery Sprint does in a week; for the AI-assisted parts of systems like this, see AI integration.