Who Controls Your Loan Origination Software Changes?

There is a conversation I have had dozens of times with COOs and Heads of Lending, usually not during a vendor demo but months or years after a platform has already gone live. It starts the same way. Someone on the operations team needs to change something small. An underwriting threshold. A stipulation requirement. The routing logic for a new loan product. And the answer they get is not “sure, give me ten minutes.” It is “let me open a ticket and check with the vendor.”

That moment is where a lot of lending organizations realize, too late, that they evaluated the wrong thing during the buying process. They tested whether the platform could handle their loan products, their approval workflows, their reporting requirements. Those are the right questions to ask. But there is a question that almost never comes up in an RFP or a demo, and it turns out to be one of the most consequential decisions a lending organization makes. Who has to be involved every time something needs to change.

Change is not the exception in lending. It is the operating condition.

Lending organizations that are growing, adapting, and competing do not operate in a static environment, and treating a loan origination platform as if it will only ever need to support today’s rules is a planning mistake. Underwriting guidelines shift based on portfolio performance and market conditions. Regulatory requirements change and have to be reflected in workflows, documentation, and disclosures. New loan products get launched to capture opportunity. Existing products get modified as the organization learns what is working and what is not. Stipulation requirements get tightened or loosened depending on risk appetite. In a healthy lending operation, these changes are not rare events. They happen monthly, sometimes more often, and the pace tends to increase as the organization scales.

The operational question this raises is straightforward but rarely asked directly during a platform evaluation. When one of these changes needs to happen, who makes it happen, and how long does it take. In some platforms the answer is that a trained operations leader logs in, updates the rule, tests it, and moves on with their day. In other platforms the answer is a service ticket, a queue, a development cycle, a testing phase, and a deployment window that can stretch into weeks.

The hidden cost of the service ticket model

The lenders who describe this problem most clearly are almost always the ones who have lived through both experiences. They implemented a platform early in their growth that required developer involvement for every configuration change, and later moved to one that did not. The difference in operational agility between those two experiences is not incremental. It is enormous, and it shows up in ways that rarely get captured in a vendor comparison spreadsheet.

Here is what actually happens while a change request sits in a queue. The operations leader already knows what needs to change and why. They are not waiting because they are uncertain. They are waiting because the system will not let them act on their own knowledge. Meanwhile the team still has to serve borrowers and process loans under the old rule, or worse, they build a workaround. That workaround is almost always a spreadsheet tracking exceptions, an email chain documenting a manual override, or a side process that exists outside the system of record. The platform that was supposed to eliminate manual work and operational risk becomes, in that moment, the reason manual work and operational risk exist. The team is not failing to use the technology correctly. The technology was not designed to keep pace with how the business actually operates.

This is the part that tends to get missed during procurement. A platform’s capability list describes what the system can do on day one. It says nothing about how the organization will adapt that system over the next five years, and adaptation is where the real operational cost or benefit shows up.

Configurability and customization are not the same thing

It is worth being precise here, because these two words get used interchangeably and they describe fundamentally different operating models. Customization means altering the underlying code of a platform to make it do something it was not originally built to do. Customization requires developers, whether internal or from the vendor. It creates technical debt that accumulates with every change. It makes every future upgrade more complicated, because custom code has to be retested and often rewritten every time the underlying platform changes. Customization can solve an immediate problem while quietly creating a long-term maintenance burden.

Configurability is a different design philosophy entirely. A configurable platform is built from the ground up with the assumption that business rules will change, and it gives trained business users a defined, governed interface for making those changes without touching code. Underwriting criteria, workflow triggers, approval thresholds, document requirements, and loan product parameters are treated as data and settings that operations leaders manage, not as logic buried in code that only a developer can touch. No code. No service ticket. No multi-week wait.

The distinction matters because it determines who owns the system going forward. In a customized environment, ownership effectively sits with whoever wrote the code, whether that is an internal IT team or the vendor’s development staff. In a configurable environment, ownership sits with the people who understand the lending business, which is exactly where it should sit. The operations leader who knows why a stipulation needs to change, or why a new product needs a different documentation flow, is the same person who can make that change happen.

What genuine configurability looks like in practice

A well-designed lending platform separates the rules of the business from the mechanics of the software. Underwriting rules, workflow logic, approval hierarchies, and document requirements are exposed through an administrative layer that a trained non-technical user can navigate. That does not mean anyone in the organization can change anything at any time. Governance still matters, and a mature platform builds in permissions, version history, and audit trails so that changes are tracked, reversible, and compliant. The goal is not to remove control. It is to move control to the right place, with the right guardrails, instead of routing every change through a technical bottleneck.

This is where the difference between a demo and a real operating environment becomes obvious. In a demo, a vendor can show a system handling a defined set of loan products under a defined set of rules, and it will look impressive because it was built and tested to look impressive under exactly those conditions. What a demo rarely shows is what happens six months later when the organization needs to launch a new loan product with different underwriting criteria, different documentation requirements, and a different approval chain. That is the moment configurability either proves itself or reveals its absence.

Why this becomes a five-year decision, not a today decision

Every platform evaluation should include a version of this question, stated plainly. Can the system do what we need it to do today. That is necessary but not sufficient. The more important question is who is going to be in control of this system as our needs change over the next five years. That single question surfaces whether a platform will function as a strategic asset that the organization can shape and adapt, or as a managed dependency that requires ongoing outside involvement every time the business evolves.

Lending organizations that answer this question early tend to build very different implementation plans than organizations that skip it. They ask vendors to demonstrate configuration changes live, not just show finished screens. They ask how a new loan product is actually launched, step by step, and who is capable of doing each step. They ask what happens when a regulatory change requires an immediate update to a disclosure workflow, and how long that update realistically takes from decision to production. These are not exotic questions. They are the same operational due diligence lenders apply to underwriting decisions, applied instead to the platform that will run their operation.

The operational payoff of self-directed configuration

When operations leaders can configure their own platform, the effects show up across the organization, not just in IT efficiency. Compliance teams can respond to regulatory changes on a timeline measured in days rather than sprint cycles. Product teams can launch and iterate on new loan offerings without a multi-month development project attached to every idea. Underwriting teams can adjust risk criteria as portfolio data comes in, instead of running exception processes while a change request works through a backlog. Perhaps most importantly, the operations team develops a sense of ownership over the system they use every day, because they are not dependent on someone else’s schedule to do their job well.

That sense of ownership compounds over time. Teams that can shape their own tools tend to use those tools more fully, document their processes more consistently, and catch operational issues earlier, because the system reflects how they actually work rather than how it was configured during a implementation project years earlier. Teams that are locked out of configuration tend to drift toward workarounds, and those workarounds become the real operating system of the business, invisible to leadership and invisible to audit.

A different way to evaluate the next platform decision

For a lending organization currently evaluating loan origination and servicing software, or reconsidering a platform that has become a source of friction, the most useful exercise is to stop asking only what the system can do and start asking who will be doing it. Ask to see a business user, not a developer, change an underwriting rule during the evaluation. Ask how a new loan product actually gets built and launched, and how long that process takes end to end. Ask what governance and audit controls exist around configuration changes, because flexibility without control is its own kind of risk.

The lending organizations that get this right are not choosing configurability instead of capability. They are recognizing that configurability is what allows capability to keep up with a business that will look different in three years than it does today. Loan origination software and workflow automation only deliver lasting value when the people running the lending operation can shape the system as the operation grows. Everything else is a snapshot of what the business needed on the day the contract was signed.