{"id":60,"date":"2026-09-09T09:33:01","date_gmt":"2026-09-09T09:33:01","guid":{"rendered":"https:\/\/barrymind.com\/?p=60"},"modified":"2026-09-09T09:36:24","modified_gmt":"2026-09-09T09:36:24","slug":"why-is-mortgage-software-so-damn-complicated","status":"publish","type":"post","link":"https:\/\/barrymind.com\/?p=60","title":{"rendered":"Why Is Mortgage Software So Damn Complicated?"},"content":{"rendered":"\n

<\/h1>\n\n\n\n

I’ve been working on mortgage software for a few years now, and there is one thing I still find a little funny.<\/p>\n\n\n\n

A mortgage loan sounds like a pretty straightforward thing.<\/p>\n\n\n\n

Someone wants to borrow money to buy a house. The lender checks the borrower, checks the property, calculates some numbers, generates some documents, and eventually closes the loan.<\/p>\n\n\n\n

So why does it take so many systems to do all of that?<\/p>\n\n\n\n

In our environment, for example, we have MeridianLink, Encompass\/Vesta, ClosingCorp, Docutech, a CRM, Surge, and quite a few other services and integrations.<\/p>\n\n\n\n

And no, this isn’t one giant application with a few modules.<\/p>\n\n\n\n

These are actually different systems, owned by different vendors, doing different things, and talking to each other.<\/p>\n\n\n\n

At some point I started wondering: why did mortgage software end up like this?<\/strong><\/p>\n\n\n\n

I don’t think the answer is simply “legacy systems.”<\/p>\n\n\n\n

Legacy is certainly part of it. But I think that’s only the last layer of the onion.<\/p>\n\n\n\n

The real problem is that the mortgage business itself has a ridiculous amount of complexity.<\/p>\n\n\n\n

First, the rules keep changing<\/h2>\n\n\n\n

Mortgage is heavily regulated, and the rules aren’t exactly known for sitting still.<\/p>\n\n\n\n

There are federal requirements, state-specific requirements, agency guidelines, loan program requirements, and probably a few things I’m forgetting.<\/p>\n\n\n\n

And when a rule changes, the software has to change with it.<\/p>\n\n\n\n

The annoying part is that a rule change rarely affects just one place.<\/p>\n\n\n\n

A change in one piece of business logic can affect calculations, eligibility, disclosures, underwriting, or documents. Sometimes it also affects data that has already been sent to another system.<\/p>\n\n\n\n

So from a developer’s perspective, “we need to support this new requirement” can mean much more than adding one if<\/code> statement.<\/p>\n\n\n\n

Although, let’s be honest, sometimes it does start with an if<\/code> statement.<\/p>\n\n\n\n

And then six months later you’re wondering why that if<\/code> statement is now being called from five different places.<\/p>\n\n\n\n

Then you have the investors<\/h2>\n\n\n\n

This is another thing that makes mortgage software interesting.<\/p>\n\n\n\n

There isn’t always one universal answer to the question:<\/p>\n\n\n\n

“Is this loan okay?”<\/strong><\/p>\n\n\n\n

The answer can depend on who is going to buy the loan.<\/p>\n\n\n\n

Different investors can have different requirements.<\/p>\n\n\n\n

They may have different rules around income, assets, property types, LTV, documentation, eligibility, and all kinds of other details.<\/p>\n\n\n\n

So you can end up with something like:<\/p>\n\n\n\n

\n

This loan is fine.<\/p>\n<\/blockquote>\n\n\n\n

followed immediately by:<\/p>\n\n\n\n

\n

Fine for whom?<\/p>\n<\/blockquote>\n\n\n\n

That’s a very important distinction in mortgage software.<\/p>\n\n\n\n

You aren’t always implementing one set of rules.<\/p>\n\n\n\n

You’re implementing rules that may depend on the loan program, the investor, the product, and sometimes a combination of several other factors.<\/p>\n\n\n\n

And of course, those requirements change too.<\/p>\n\n\n\n

So now we have changing regulations and<\/strong> changing investor requirements.<\/p>\n\n\n\n

Great.<\/p>\n\n\n\n

And then we need other systems<\/h2>\n\n\n\n

This is where the architecture starts getting fun.<\/p>\n\n\n\n

We could theoretically build everything ourselves.<\/p>\n\n\n\n

But why would we?<\/p>\n\n\n\n

If a company specializes in fee data, it makes more sense to use them than to build and maintain our own nationwide fee database.<\/p>\n\n\n\n

If another company specializes in generating mortgage documents, we’re probably better off integrating with them than trying to become a document-generation company ourselves.<\/p>\n\n\n\n

That’s how you end up with systems like ClosingCorp and Docutech alongside your core loan systems.<\/p>\n\n\n\n

In our case, Encompass\/Vesta is one of the major pieces of the loan workflow. MeridianLink is another important part of the overall process. ClosingCorp handles fee-related data, and Docutech is used for document generation.<\/p>\n\n\n\n

Then there is CRM.<\/p>\n\n\n\n

We used Surefire before and now use NextWave.<\/p>\n\n\n\n

And there is Surge, which handles another part of the ecosystem.<\/p>\n\n\n\n

There are also systems I know well enough to work with, systems I know just enough to integrate with, and systems where I occasionally have to ask, “Wait, what exactly does this thing do again?”<\/p>\n\n\n\n

That’s probably a normal day in mortgage technology.<\/p>\n\n\n\n

The point is that each system solves a particular problem.<\/p>\n\n\n\n

The problem is that the loan has to move through all of them.<\/p>\n\n\n\n

Now we have the fun part: data<\/h2>\n\n\n\n

Once you have multiple systems, you inevitably end up with multiple copies of the same loan data.<\/p>\n\n\n\n

Loan amount.<\/p>\n\n\n\n

Property information.<\/p>\n\n\n\n

Borrower information.<\/p>\n\n\n\n

Income.<\/p>\n\n\n\n

Fees.<\/p>\n\n\n\n

Dates.<\/p>\n\n\n\n

And a lot of other fields.<\/p>\n\n\n\n

Then someone changes something.<\/p>\n\n\n\n

This is where things get interesting.<\/p>\n\n\n\n

Which system changed first?<\/p>\n\n\n\n

Which system is the source of truth?<\/p>\n\n\n\n

Should we pull the value again, or use what we already have?<\/p>\n\n\n\n

How old can our copy of the data be?<\/p>\n\n\n\n

What happens if the other system is temporarily unavailable?<\/p>\n\n\n\n

What happens if two systems disagree?<\/p>\n\n\n\n

These are not particularly exciting questions when you’re building a simple web application.<\/p>\n\n\n\n

In mortgage software, they can become very important questions.<\/p>\n\n\n\n

I’ve had plenty of situations where the technically easiest solution wasn’t necessarily the right one because we had to think about data consistency, performance, or the behavior of another system.<\/p>\n\n\n\n

Sometimes you want real-time data.<\/p>\n\n\n\n

Sometimes calling another system every time is too expensive or too slow.<\/p>\n\n\n\n

Sometimes you need a cache.<\/p>\n\n\n\n

And once you have a cache, congratulations \u2014 now you have to think about stale data.<\/p>\n\n\n\n

There is no free lunch.<\/p>\n\n\n\n

A field is rarely just a field<\/h2>\n\n\n\n

This is probably one of the things that took me the longest to appreciate.<\/p>\n\n\n\n

When you look at a mortgage system, a field can look completely innocent.<\/p>\n\n\n\n

Change the value.<\/p>\n\n\n\n

Save it.<\/p>\n\n\n\n

Done.<\/p>\n\n\n\n

Except that field might be used by another calculation.<\/p>\n\n\n\n

That calculation might affect a fee.<\/p>\n\n\n\n

The fee might affect a disclosure.<\/p>\n\n\n\n

The disclosure might be generated by another system.<\/p>\n\n\n\n

And somewhere else, an investor might have a rule that depends on the original value.<\/p>\n\n\n\n

So the question isn’t just:<\/p>\n\n\n\n

\n

Where is this field stored?<\/p>\n<\/blockquote>\n\n\n\n

It’s also:<\/p>\n\n\n\n

\n

Who cares about this field?<\/p>\n<\/blockquote>\n\n\n\n

And sometimes:<\/p>\n\n\n\n

\n

Who cares if this field changes?<\/p>\n<\/blockquote>\n\n\n\n

That’s a very different problem.<\/p>\n\n\n\n

Then there’s the history<\/h2>\n\n\n\n

Eventually, all of this has to live somewhere.<\/p>\n\n\n\n

And the mortgage industry has been doing this for a long time.<\/p>\n\n\n\n

New regulations get added.<\/p>\n\n\n\n

New investors come along.<\/p>\n\n\n\n

New products are introduced.<\/p>\n\n\n\n

New vendors are integrated.<\/p>\n\n\n\n

Companies replace one platform with another.<\/p>\n\n\n\n

But nobody gets to stop processing loans for three years while they redesign the entire architecture.<\/p>\n\n\n\n

So you keep adding things.<\/p>\n\n\n\n

And adding things.<\/p>\n\n\n\n

And eventually you have a system that has been through enough changes that nobody is completely sure what all of it does anymore.<\/p>\n\n\n\n

That’s what we call a legacy system.<\/p>\n\n\n\n

As developers, we tend to make fun of legacy code.<\/p>\n\n\n\n

I’ve certainly done it.<\/p>\n\n\n\n

You open some code and think:<\/p>\n\n\n\n

\n

“Who wrote this?”<\/p>\n<\/blockquote>\n\n\n\n

Then you discover that the code was written twelve years ago, has processed millions of dollars of loans, and is still running in production.<\/p>\n\n\n\n

At that point, maybe the better question is:<\/p>\n\n\n\n

\n

“What happened over those twelve years?”<\/p>\n<\/blockquote>\n\n\n\n

Because there is usually a reason.<\/p>\n\n\n\n

The ugly piece of code may be supporting an investor requirement that existed ten years ago.<\/p>\n\n\n\n

That weird database table may exist because another system couldn’t handle the data any other way.<\/p>\n\n\n\n

That strange API behavior may be there because someone integrated with a vendor years ago and changing it would break three other things.<\/p>\n\n\n\n

The code isn’t necessarily a representation of good architecture.<\/p>\n\n\n\n

Sometimes it’s a representation of everything the business has asked the software to survive.<\/strong><\/p>\n\n\n\n

That’s probably why mortgage software is so complicated<\/h2>\n\n\n\n

After working with it for a while, I’ve stopped thinking of the complexity as one big software problem.<\/p>\n\n\n\n

It’s more like several different kinds of complexity stacked on top of each other.<\/p>\n\n\n\n

The regulations change.<\/p>\n\n\n\n

Investors have different requirements.<\/p>\n\n\n\n

Loan programs have different rules.<\/p>\n\n\n\n

Third-party systems provide specialized services.<\/p>\n\n\n\n

Multiple applications need to exchange data.<\/p>\n\n\n\n

And all of that sits on top of years \u2014 sometimes decades \u2014 of existing software.<\/p>\n\n\n\n

So when someone says:<\/p>\n\n\n\n

\n

“It’s just a small change.”<\/p>\n<\/blockquote>\n\n\n\n

I have learned not to react too quickly.<\/p>\n\n\n\n

It might actually be a small change.<\/p>\n\n\n\n

Or it might be one of those changes where you start with one field and end up tracing data through four systems, three APIs, two business rules, and a disclosure document.<\/p>\n\n\n\n

You never really know.<\/p>\n\n\n\n

And honestly, that’s one of the things I find interesting about working on mortgage software.<\/p>\n\n\n\n

The architecture isn’t just an architecture.<\/p>\n\n\n\n

It’s a record of the business decisions, regulations, integrations, and compromises that came before it.<\/strong><\/p>\n\n\n\n

Once you start looking at it that way, even some of the strangest parts of the system begin to make a little more sense.<\/p>\n\n\n\n

Not necessarily less complicated.<\/p>\n\n\n\n

Just a little more understandable.<\/p>\n","protected":false},"excerpt":{"rendered":"

I’ve been working on mortgage software for a few years now, and there is one thing I still find a little funny. A mortgage loan sounds like a pretty straightforward thing. Someone wants to borrow money to buy a house. The lender checks the borrower, checks the property, calculates some numbers, generates some documents, and … Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-60","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/posts\/60","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/barrymind.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=60"}],"version-history":[{"count":2,"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/posts\/60\/revisions"}],"predecessor-version":[{"id":62,"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/posts\/60\/revisions\/62"}],"wp:attachment":[{"href":"https:\/\/barrymind.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=60"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/barrymind.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=60"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/barrymind.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=60"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}