The problem was obvious the first time we watched an underwriter work. Not obvious in the way that makes you feel clever for noticing. Obvious in the way that makes you feel embarrassed it hadn't been solved.
The underwriter had the deal in front of her. Twelve months of bank statements. A credit report. Three MCA agreements with different funders. A tax return. She knew what she was looking for. She had done this for eleven years. The judgment was there. What she was doing, for the first forty minutes of a sixty-minute file, was assembly. Moving numbers from PDFs into a spreadsheet. Classifying positions by funder. Building the stacking picture by hand.
She wasn't thinking during that time. She was copying. The thinking came at the end, in the twenty minutes that were left, which was not enough time to think carefully about a decision that involved real money and real risk. The constraint wasn't her. It was the work that preceded her.
We had seen versions of this problem before. In every knowledge-intensive industry, there is a gap between the work that requires judgment and the work that precedes it. The preceding work is mechanical. It is gathering, formatting, classifying, reconciling. It does not require expertise. It consumes the time of the people who have it.
Lending is an extreme case. The documents are dense. The formats are inconsistent. A bank statement from one institution is structured differently than the same document from a competitor. Credit reports have their own conventions. MCA agreements bury position terms in boilerplate. None of it is designed to be processed at scale. All of it has to be processed before the underwriter can do anything.
The standard response to this problem in software is automation. Build a model. Replace the human. This is the wrong frame. Underwriting is not a process with a correct output that can be approximated. It is a judgment call made by a person who has pattern-matched across hundreds of files. Two experienced underwriters can look at identical numbers and price differently. Both can be right. The goal is not to eliminate that judgment. The goal is to get the underwriter to the point where the judgment can be applied faster.
Pathway is the infrastructure between the document and the decision. We parse bank statements across every format we have encountered, and we have encountered most of them. We classify positions. We build the stacking picture. We calculate debt service coverage. We surface the signals the underwriter needs before they have to go looking.
The underwriter still decides. That was always the point. What changes is how much of their time is spent on the file and how much of that time is spent thinking versus copying. The assembly goes away. The judgment stays.
We are building this for the people who actually do the work. Not for the executive who wants a dashboard. Not for the investor who wants a risk score. For the underwriter who opens a file at nine in the morning and needs to be done with it by eleven. That is the user we are optimizing for, and that is the user we will continue to optimize for.
Everything else follows from that.