Rethinking What You Spend on LOS Admin

November 11, 2025

Most mid-sized lenders in the U.S. spend real money just keeping their loan origination system running. Many keep one or more highly paid LOS administrators on staff to handle daily needs or have to commit to a steady services bill with their LOS vendor. Larger lenders on more monolithic LOS platforms may pay millions every year just to maintain and extend the system.

This article looks at what those admins actually do, which of those tasks are truly part of the mortgage business, and which are side effects of the platforms themselves. It closes with a picture of what a better platform would look like—one that trims away unnecessary admin work while still protecting compliance, quality, and speed.

Why these admin costs exist

Mortgage lending is complicated. Rules change often. Product lines shift with the economy. Secondary market partners ask for different data or introducing novel products. States update forms. All of this creates motion in your workflows, your rules, and your documents. Someone has to translate business changes into system behavior. That is the fair and necessary part of admin work.

But platforms also come with their own gravity. Some are hard to configure. Some make small changes feel risky, so teams build layers of testing and sign-off around even simple updates. Some require custom code for tasks that should be point-and-click. Some have fragile integrations that break when a vendor changes an API. And worst of all, some give non-programmers the ability to “fix” stuff that there are unequipped to properly fix.  Those are not business needs—they are platform taxes. The trick is telling the difference.

What Encompass admins really do all day

If you sit beside a strong LOS admin for a week, you’ll see a rhythm. They start with clear understanding of how they impact business value (or cost/risk avoidance).  They efficiently translate policy updates into rules and they are methodical at ensuring the rules are applied in every place they are required, not just the obvious happy-path.

They add custom fields and forms only when it is necessary. They make sure that when new disclosures come out from a state that they are fully vetted in advance and verified in production.

They ensure quality data and document management so that investors and vendors get consistency and post-close noise is lessened. They troubleshoot when a doc package won’t generate or an automated check misfires. They fix access issues and clean up permissions when roles change so that your security posture is sound. They may even watch queues, reports, and pipelines to ensure everything is running smoothly.

All of those activities sound like “admin work,” but they are not equal. Some directly protect the business, like keeping you compliant or keeping loans moving to closing. Some simply compensate for system gaps, like hand-maintaining field mappings across screens or babysitting brittle integrations that drop data.

The true cost of ownership in plain terms

When leaders think about tech admin cost, they often think about salaries. For a mid-sized lender, that might be one senior admin and one analyst, plus some consulting hours during busy seasons. But the real cost is larger.

There is the time your sales and ops teams spend waiting for changes or re-keying the same data. There is the risk that a “small” change breaks a critical rule and causes defects. There is the drag on speed to market when it takes weeks to push a workflow fix. There is the ongoing technical debt from quick fixes that never get cleaned up. And there is the vendor ecosystem you stitch together—docs, pricing, credit, VOE/VOI, AUS, secondary, imaging—and the care and feeding each integration needs.

In a legacy, monolithic LOS, these costs scale up fast. Custom add-ons, one-off scripts, and unique data models make upgrades painful. A major release can trigger months of retesting. That is how annual spend climbs into the millions for larger lenders: not just licenses, but the people and time absorbed by keeping the machine from shaking itself apart.

Which tasks are part of the business vs. platform-inflicted

It helps to sort common admin activities into two buckets: “mortgage-native” work that you will always need, and “platform-induced” work you only do because the tool makes you.

Changing loan products, pricing levers, fees, and disclosures is mortgage-native. Investors change overlays, agencies update rules, and states update forms. You need the ability to reflect those changes quickly and safely. Data stewardship is also mortgage-native. You have to ensure the same fact—like borrower income—stays consistent everywhere it appears, from the application to the AUS to the investor file. Access control and audit are mortgage-native as well, since you must protect consumer data and show who did what, when.

By contrast, many recurring chores are platform-induced. If adding a field takes hours because it must be manually wired to multiple screens and exports, that is the platform. If a release breaks your custom rules because the vendor changed field IDs or event timing, that is the platform. If integrations fail silently and require daily babysitting, that is the platform. If reporting requires copied data sets because the built-in data model is closed or inconsistent, that is the platform. If every change demands a full regression cycle because there is no safe sandbox, no impact analysis, and no feature flags, that is the platform.

The same is true for training load. Some training is natural when people and products change. But if new hires need weeks to learn where the system “hides” basic steps, the user experience is pushing admin cost into the business. 

Industry-standard rules vs. lender-unique rules

A key source of waste is writing rules that should have been included in the platform from the start. There is a broad class of rules that are industry standard. These include agency rules from Fannie Mae and Freddie Mac, FHA and VA eligibility checks, federal disclosures, common state-specific forms and timelines, fair lending and HMDA validations, basic TRID timing checks, and standard data validations for AUS submissions. These rules are stable enough and common enough that a platform should ship them as built-in, up-to-date, and versioned configurations. They should update automatically when regulators or agencies make official changes, with clear release notes and safe rollout paths. When a platform treats these standards as plug-and-play, your admins do not spend their time re-describing the mortgage industry to the software.

On the other side are lender-unique rules. These grow from your strategy, your risk appetite, your overlays, your pricing tiers, your niche products, your fulfillment model, and your operational preferences. Maybe you require extra documentation for self-employed borrowers beyond the agency minimums. Maybe you have tighter DTI caps for certain products, or you route certain loans to a specialist team. These are real business choices, and the system should let you express them clearly without code. Your admin time should go here, because this is where rules create competitive advantage and protect your brand.

The mistake many lenders are forced into is spending heavy time on both categories. They re-implement industry standards because the platform does not ship them ready-made, and they also fight the tool to encode their unique rules. The first pile is pure waste. The second pile should be fast and safe, not painful and risky.

Preventing rework should be native, not an admin side project

Front-line teams lose hours when the system allows incomplete or inconsistent data to move forward. When loan files bounce back for missing items, your cost per loan goes up and your cycle time stretches. It should not be an admin’s job to dream up and hand-build a web of checks to block bad handoffs. Preventing rework should be native to the platform. The application should guide the user step by step, prompting for the next right piece of information and validating it in the moment. The platform should understand dependencies, so it knows when a new fact changes earlier answers and it asks for a refresh. It should highlight exceptions and missing items early, and it should not let a loan move past a milestone with known defects.

When this quality control is built in, your admins stop playing traffic cop. They are no longer writing patchwork rules to catch routine mistakes. Instead, they focus on the small slice of checks that are truly unique to your lending model. That shift moves admin time from “fixing the tool” to “improving the business,” which is where enterprise value is created.

Custom forms should be rare, because the platform should adapt to you

Some lenders end up building custom data entry forms just to make the work tolerable. They do this because the out-of-the-box screens do not match the way their teams operate, or because key fields are hard to find. That is a destruction of value. Every custom form brings setup time, training time, and maintenance time. When a vendor releases a new version, those forms can break or fall out of sync. When you change a workflow, you have to touch the forms again. None of this helps you close more loans.

A better approach is a platform that adapts to your process without heavy custom builds. Screens should be role-aware and milestone-aware by default. A processor should see what a processor needs, in the order they work. A closer should see what a closer needs. The platform should let you rearrange and label fields with simple configuration, not code, and it should keep those choices safe through upgrades. If you need a new field, you should define it once and have it appear where it belongs across the app, the AUS payload, the investor export, and the data warehouse—with no extra mapping marathons.

A small aside…in a recent meeting with a client, someone brought up the book The Design of Everyday Things by Don Norman.  When you take the basic premise of good design and then stop to look at what LOS vendors have created, it’s amazing how the short-sightedness of software developers has effectively crippled productivity.  Most programmers build what they consider to be perfectly logical software.  The problem is that logic rarely equals the way work actually needs to be done or how your team expects to work with software.  It’s amazingly simple to think that a big part of minimizing admin work and expenses is having a platform that is thoughtfully designed before it is programmed!

So what is a realistic minimum?

If you strip away platform-induced work and focus on what the business truly needs, the baseline is much slimmer than many shops carry today.

You still need a product owner for lending workflows and compliance updates…but that may not need to be a tech person. 

You need someone who can translate rule changes into system behavior and who can coordinate testing with operations. This minimally requires someone who understands processes and, ideally, why software engineering works the way it does.

You need attention to data quality, reporting, and access control. And you need a small vendor budget for edge cases or specialist reviews during heavy change windows.

In that “healthy minimum” state, the daily work shifts from hand-tuning and firefighting to controlled change management. The cadence becomes weekly updates instead of constant fixes. Training moves from “how to work around the tool” to “how to do the job.” Reporting is pulled from a trustworthy, well-labeled data layer instead of one-off extracts. You manage vendor relationships and, in so doing, formally plan-out integration changes/upgrades when vendors change something. The team still exists, but its time goes toward business outcomes instead of patching the tool.

Where admins create true enterprise value

Strong admins create value when they shorten cycle times, reduce defects, and help the front line close more loans with fewer touches. They do this by turning policy into rules that prevent rework, by removing clicks that slow down the pipeline, and by catching data issues before they reach investors. They also reduce risk by keeping you current on forms and disclosures and by maintaining clean permissions and audit trails. Those are all enterprise value levers: speed, quality, certainty, and reputation.

Admins destroy value when they are forced to spend most of their time on tasks with little business impact, like reconnecting brittle integrations, remapping fields across multiple places, or retesting the same workflows after every small release. If you measure admin work through that lens—time spent on outcomes vs. time spent on tool friction—you will see where your platform is taxing you.

The cost gap between modern and monolithic LOS

Modern platforms that prefer configuration over custom code shrink the cost of change. They offer opinionated defaults for standard workflows so you start close to “good” and only adjust the edges. They keep a stable, documented data model so your rules and reports do not break when the vendor ships a release. They provide sandboxes, impact analysis, and easy rollback so change is safe and fast. They expose open APIs that version cleanly, so integrations don’t snap under normal updates. With that foundation, a mid-sized lender’s admin footprint can be lean without adding risk.

Monolithic systems push the other way. Unique data models, limited guardrails, and upgrade shocks make every change heavy. Customizations pile up. Over time, you are paying not just for the system, but also for the complexity you have unknowingly built into it. That is how “normal” admin staffing turns into a permanent mini-IT department, even when your business has not grown.

A simple test for your own shop

Pick three recent changes—a new fee, a small workflow tweak, and a new export or report. Ask how long each took from request to production, how many people touched it, how much testing was needed, and whether anything else broke. If answers show long delays, many handoffs, heavy testing, and frequent breakage, you are seeing platform-induced work. If answers show quick turns, clear ownership, light testing, and no surprises, you are closer to the realistic minimum.

What a platform would look like that removes unnecessary admin work

A better platform starts with a clean, stable data model so the same fact is defined once and used everywhere.

• Rules and workflows live as versioned configurations that can be promoted from a sandbox with a click, with clear impact analysis that tells you what will change and where.
• Common mortgage tasks come with smart defaults—standard disclosures, standard milestones, standard validation checks—so you only fine-tune instead of building from scratch.
• Integrations are treated like first-class citizens, with managed connectors that version alongside vendors and can retry, self-heal, and alert when something changes.
• Reporting draws from a single, well-labeled data layer that updates in near real time, so teams do not need extracts or shadow databases.
• Releases are boring because they are backward-compatible and come with migration guides that the system can apply for you.
• Access control is simple and role-based, with clear audit trails and easy reviews.
• And the user experience guides people to do the next right thing, which lowers training time and reduces errors without heavy admin oversight.

In this model, industry-standard rules arrive built-in and kept current by the platform, while lender-unique rules are easy to express in plain language and safe to deploy. Rework prevention is not a project—it’s in the DNA of the application. Custom forms become rare, because the platform meets teams where they are. When a platform works like this, your admin function becomes a small, focused team that steers change, guards data quality, and supports the business in moving faster with confidence. The cost does not go to zero, because the mortgage business will always change. But the spend you once treated as a fact of life—re-mapping, re-testing, re-training, and re-fixing—drops away. What is left is the true minimum: the work that actually adds enterprise value.

It’s a fact of mortgage life that every lender is constantly re-assessing the value proposition of their tech stack.  Next time you do your own math, make sure you consider the platform tax you’re paying for admin work…not just the dollars, but the drag on your speed of execution not to mention your team’s morale.