Every Mortgage Takes 20 Systems. That's the Problem
It’s Wednesday afternoon and a processor I know has eighteen tabs open across two monitors for a single file.
POS. LOS. Credit. Income verification. Asset verification. Fraud. AUS. Flood cert. Appraisal portal. MI portal. Investor portal. Title. Esign. Closing platform. Doc storage. The CRM where she logged the call this morning. A Slack channel where ops is asking her where it is. An email thread where the borrower is asking the same thing.
She isn’t behind. She isn’t bad at her job. This is what normal looks like for this file to live through.
None of those tools is broken. Each one is, in fact, the best version of itself the market has produced. She isn’t fighting bad software. She’s fighting the space between good software.
That space has a name nobody at the company can find on a P&L. It’s where work goes to wait. Documents living in three places. Conditions cleared in one system, still showing open in another. Status meetings whose entire purpose is to figure out which tool the file is currently sitting in. Borrowers ghosted not because anyone forgot, but because every tool was sure someone else was handling it.
You don’t have a tool problem. You have an architecture problem. And nobody on your team owns the architecture.
Open any mortgage operation and count the systems a single file touches between application and funding. You’ll get to twenty without trying. POS to CRM to credit pull to income and employment verification to asset verification to fraud check to LOS to underwriting workflow to AUS portal to flood cert to appraisal vendor to MI portal to investor portal to compliance check to title to esignature to closing platform to doc storage to email and Slack carrying state across all of it.
Twenty is the low end. Some lenders are at thirty.
Each of those tools has a champion who fought for it. Each was the right purchase in isolation. Each one produces metrics that look good on a vendor scorecard. None of them know about the file as a whole.
This is what the industry calls “best of breed.” In practice it became accumulating. Not integrating.
Clayton Christensen spent a career studying what happens when industries assume they’ve reached the modular stage of their lifecycle. His law of conservation of modularity is blunt. When end to end performance is not yet good enough on the dimensions customers care about, integrated architectures win, because the performance gains live in the integration. Once components become good enough, value migrates outward to modular providers competing on cost.
Mortgage tech assumed it was at the modular stage. It isn’t.
Borrower cycle time is not good enough. Borrower certainty is not good enough. The unit cost of producing a file is not good enough. None of the dimensions a borrower can feel, or a CFO can sleep with, are good enough.
So the math doesn’t work. Buying the best individual modules and snapping them together doesn’t produce a better mortgage. It produces a fragmented mortgage with the seams visible to the borrower.
The MBA’s Q1 2026 Quarterly Performance Report puts the average IMB production cost at $11,898 per loan, against a long term average near $7,900 and a current pretax profit of $727 per loan. That’s nearly $11,200 of stack burden riding on a sliver of margin.
Some of that is labor. Some is compliance. A real chunk is what I’ve started calling the Integration Tax. The cost that lives in the seams between tools.
Rekeying the same data four times.
Reconciling status across three systems before anyone can answer “where is this file?”
A processor spending forty minutes a day chasing a document that was already uploaded, just to the wrong tool.
The Integration Tax doesn’t appear on a vendor invoice. It hides inside payroll and cycle time. Which is exactly why nobody fixes it. The cost is real. It’s just nobody’s job.
Donella Meadows put it cleanly in Thinking in Systems: the structure of a system is the source of its behavior. If your behavior is an $11,898 production cost and a 42 day cycle that hasn’t materially moved in years, that isn’t a labor problem, and it isn’t a tool problem. It’s a structural problem dressed up as a thousand small inefficiencies.
Meadows ranked twelve leverage points for changing a system. The weakest interventions, the ones with the lowest payoff, are parameters. Buy a faster credit tool. Hire two more processors. Tighten an SLA. The strongest leverage points are the goals, the paradigm, and the structure of the system itself.
Reading the average mortgage tech roadmap is reading a document that lives almost entirely at the bottom of that hierarchy.
So what does “Kill the Stack” actually mean here?
Not rip and replace. Not build it all yourself. The industry has tried both versions of that. The in house custom LOS graveyard. The giant rip and replace transformations that cost millions and end with a different fragmented stack.
Kill the Stack means stop treating the accumulated tools as the architecture.
The architecture is the file moving end to end. The tools are inputs to it. Right now, in most lending operations, no one owns that file’s journey. The CIO owns infrastructure. The COO owns process. The CTO owns engineering. The vendors own their tools. The file owns no one.
This is where AI and agentic systems are actually useful. Not as another product to bolt onto the stack, but as the connective tissue the file has been missing. Holding state across the seams. Moving data between tools the way a coordinator does today, except continuously and without forgetting. Clearing conditions where they’re already provably clear. Telling the borrower what’s happening without the borrower having to ask.
That’s a different shape than “buy an AI feature.” It’s an architectural commitment that the file, not the tool, is the unit of design.
The industry has been buying tools for fifteen years. Cycle times haven’t materially improved. Costs are higher, not lower. Pull-through has declined every year for the past four (MBA, October 2025).
The next decade isn’t about buying better tools. It’s about deciding that someone, a person, a team, an architecture, owns the file end to end. Until that decision gets made, the Integration Tax keeps compounding. Quietly. Automatically. Every file.
Twenty systems isn’t the problem because twenty is a big number. It’s a problem because nobody designed the connection between any two of them.
That’s the architecture nobody owns.
That’s the stack worth killing.
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.