Underwriting Isn’t Slow. Your Stack Is
I was speaking with a mortgage lender last week, and I asked the typical sales question: what is your biggest challenge today? My goal, of course, was to find a way to help solve their problem with something we offer or could offer the market. What was interesting was their response. Their biggest challenge, at least that week, was files sitting pending for days and sometimes weeks. For those in ops teams, I’m sure you’ll jump to processing, and rightfully so. Waiting on docs is normally the culprit. But it wasn’t. They had a loan sitting untouched for nearly three days, in underwriting. When I pulled the thread a little more, I came to realize it wasn’t the credit decision taking that long. The part where a human looked at the borrower’s income, assets, and risk profile and made a judgment call took about thirty minutes.
The other two days and twenty-three hours? Waiting. Waiting for a document that had been uploaded to one system but hadn’t synced to another. Waiting for an income calculation that required data from three different sources, none of which shared a format. Waiting for a condition to clear that had already been resolved in a different tool but hadn’t propagated to the one the underwriter was looking at.
The underwriter wasn’t slow. The infrastructure around her was.
This is the part that most people in lending get wrong. “Underwriting is the bottleneck” has become gospel, repeated in board decks, vendor pitches, and ops meetings like it’s an obvious truth that just needs a better solution. So lenders hire more underwriters. Add more training. Layer on more oversight. Buy AI tools that promise to make credit decisions faster.
None of it moves the needle. Because the bottleneck was never the decision. It was everything that happened before the decision could be made.
That conversation stuck with me, because it wasn’t the first time I’d heard it. I’ve had some version of this same discussion with lenders across Canada and the US. The specific file changes. The number of days changes. The tools involved change. What doesn’t change is the diagnosis: a person gets blamed for a problem that a system created.
Walk through the actual time breakdown on a typical file once it hits the underwriting queue. From submission to decision, call it 72 hours. How much of that is genuine underwriting judgment? The part where a skilled human evaluates creditworthiness, weighs compensating factors, applies guidelines to an actual borrower’s situation?
Thirty minutes. Maybe an hour on a complex file.
The rest is infrastructure. Document collection. Format reconciliation. Data validation. Condition chasing. Re-keying information that exists in one system but can’t be read by another. Waiting for third-party verifications that were ordered late because the system didn’t trigger them automatically. Staring at a queue that isn’t moving because the previous step hasn’t released the file yet.
The underwriter isn’t slow. They’re idle. Not because they aren’t working (they’ve got thirty other files they’re toggling between) but because on any given file, the system hasn’t delivered what they need to make the next decision. So they move to another file, and the cycle repeats. Context-switching across a portfolio of half-ready files, each one stuck at a different point in a broken data pipeline.
That’s not an underwriting problem. That’s a plumbing problem.
Eliyahu Goldratt spent his career studying why systems underperform. His insight, laid out in The Goal, was deceptively simple: every system has a constraint, one point that limits overall throughput. Optimize anything other than the constraint and you haven’t improved the system. You’ve just made a non-bottleneck more efficient, which means you’ve changed nothing that matters.
I kept coming back to Goldratt when we were building FundMore. Every time a lender told us their underwriting was the problem, I’d ask them to walk me through where the file actually spent its time. The answers were always the same. The underwriter wasn’t the constraint. The data movement was.
In lending, everyone assumes the constraint is the underwriter. So they optimize the underwriter. Faster guidelines engines. Better decision support. AI-assisted risk analysis. And the underwriter does get faster, at the thirty minutes of actual judgment they were already doing well. The other seventy-one hours and thirty minutes don’t move.
Donald Reinertsen, in The Principles of Product Development Flow, went further. He showed that in any complex process, wait time dominates work time, often by a factor of ten or more. The problem isn’t that individual steps are slow. It’s that invisible queues form between steps, and nobody measures them. The work sits. The clock runs. And because the queue is invisible, it doesn’t show up in any dashboard, any KPI, or any vendor report, so nobody manages it.
Reinertsen showed that invisible queues are the root cause of poor performance in any development flow, what he described as “the root cause of the majority of economic waste in product development.” In lending, they’re the time between document upload and document availability. The gap between condition request and condition response. The lag between data entry in one system and data appearance in the next. None of these are “underwriting.” All of them are what makes underwriting take three days.
Here’s what makes this worse: the standard response to a misidentified bottleneck compounds the problem instead of solving it.
I asked that lender what they’d already tried. More underwriters, they said. Better training. A new QC layer. They were about to look at an AI underwriting tool. Each one of those responses sounds reasonable. Each one misses the point entirely.
Hire more underwriters? Now you have more people waiting for the same broken data pipeline. The queue upstream hasn’t changed. You’ve just added capacity at the one point in the system that wasn’t actually constrained.
Add more oversight and QC checkpoints? Each one is another gate in an already slow flow. Another place where a file can sit, waiting for someone to look at it, before it moves to the next stage of sitting and waiting.
Deploy AI underwriting on top of the existing stack? You now have a system that can make a credit decision in three seconds, then wait seventy-one hours and fifty-nine minutes for the next file to be ready. You’ve built a jet engine and bolted it to a horse cart.
Every one of these interventions feels productive. Every one of them misses the point. The constraint isn’t judgment speed. It’s data movement. And until you fix data movement, nothing else you do to underwriting will show up in your cycle times.
What changes when you treat the stack, not the underwriter, as the constraint?
When I walked that lender through this framing, something shifted. They’d been thinking about underwriting as a stage with a person at the center. The reframe is simpler than it sounds: underwriting is a continuous activity that happens whenever the data is ready. The person was never the problem. The pipeline was.
Document collection becomes parallel, not sequential. Validation happens at the point of entry, not as a separate step downstream. Data moves through a single architecture instead of being exported, transformed, and imported across six different systems.
The underwriter stops toggling between thirty half-ready files and starts working a queue of files that are actually ready for a decision. The context-switching drops. The idle time drops. The cycle time drops. Not because the underwriter got faster. Because they stopped waiting.
This isn’t theoretical. Lenders who’ve moved to integrated, event-driven architectures, or even started agentic system, where data flows continuously rather than being batched and handed off, are seeing cycle times compress by days, not hours. Not because they replaced underwriters with AI. Because they removed the invisible queues that were making underwriters look slow.
The lender I spoke with last week isn’t unusual. Most people reading this have probably been in some version of that conversation, either telling someone their underwriters are the problem or being told it themselves.
The mortgage industry has spent two decades trying to fix underwriting. Faster tools. Smarter models. More automation at the decision layer. And underwriting cycle times have barely moved, because the decision was never what took three days.
The plumbing took three days. The data movement. The format reconciliation. The handoffs between systems that were never designed to talk to each other.
Your underwriter isn’t your bottleneck. Your stack is.
Stop hiring more people to wait faster. Fix the pipes.
Chris Grimes is the founder of FundMore, an AI-native loan origination platform. FundMore builds agentic mortgage and lending infrastructure for institutional clients across Canada and the US.