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 eventually closes the loan.

So why does it take so many systems to do all of that?

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

And no, this isn’t one giant application with a few modules.

These are actually different systems, owned by different vendors, doing different things, and talking to each other.

At some point I started wondering: why did mortgage software end up like this?

I don’t think the answer is simply “legacy systems.”

Legacy is certainly part of it. But I think that’s only the last layer of the onion.

The real problem is that the mortgage business itself has a ridiculous amount of complexity.

First, the rules keep changing

Mortgage is heavily regulated, and the rules aren’t exactly known for sitting still.

There are federal requirements, state-specific requirements, agency guidelines, loan program requirements, and probably a few things I’m forgetting.

And when a rule changes, the software has to change with it.

The annoying part is that a rule change rarely affects just one place.

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.

So from a developer’s perspective, “we need to support this new requirement” can mean much more than adding one if statement.

Although, let’s be honest, sometimes it does start with an if statement.

And then six months later you’re wondering why that if statement is now being called from five different places.

Then you have the investors

This is another thing that makes mortgage software interesting.

There isn’t always one universal answer to the question:

“Is this loan okay?”

The answer can depend on who is going to buy the loan.

Different investors can have different requirements.

They may have different rules around income, assets, property types, LTV, documentation, eligibility, and all kinds of other details.

So you can end up with something like:

This loan is fine.

followed immediately by:

Fine for whom?

That’s a very important distinction in mortgage software.

You aren’t always implementing one set of rules.

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

And of course, those requirements change too.

So now we have changing regulations and changing investor requirements.

Great.

And then we need other systems

This is where the architecture starts getting fun.

We could theoretically build everything ourselves.

But why would we?

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

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.

That’s how you end up with systems like ClosingCorp and Docutech alongside your core loan systems.

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.

Then there is CRM.

We used Surefire before and now use NextWave.

And there is Surge, which handles another part of the ecosystem.

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?”

That’s probably a normal day in mortgage technology.

The point is that each system solves a particular problem.

The problem is that the loan has to move through all of them.

Now we have the fun part: data

Once you have multiple systems, you inevitably end up with multiple copies of the same loan data.

Loan amount.

Property information.

Borrower information.

Income.

Fees.

Dates.

And a lot of other fields.

Then someone changes something.

This is where things get interesting.

Which system changed first?

Which system is the source of truth?

Should we pull the value again, or use what we already have?

How old can our copy of the data be?

What happens if the other system is temporarily unavailable?

What happens if two systems disagree?

These are not particularly exciting questions when you’re building a simple web application.

In mortgage software, they can become very important questions.

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.

Sometimes you want real-time data.

Sometimes calling another system every time is too expensive or too slow.

Sometimes you need a cache.

And once you have a cache, congratulations — now you have to think about stale data.

There is no free lunch.

A field is rarely just a field

This is probably one of the things that took me the longest to appreciate.

When you look at a mortgage system, a field can look completely innocent.

Change the value.

Save it.

Done.

Except that field might be used by another calculation.

That calculation might affect a fee.

The fee might affect a disclosure.

The disclosure might be generated by another system.

And somewhere else, an investor might have a rule that depends on the original value.

So the question isn’t just:

Where is this field stored?

It’s also:

Who cares about this field?

And sometimes:

Who cares if this field changes?

That’s a very different problem.

Then there’s the history

Eventually, all of this has to live somewhere.

And the mortgage industry has been doing this for a long time.

New regulations get added.

New investors come along.

New products are introduced.

New vendors are integrated.

Companies replace one platform with another.

But nobody gets to stop processing loans for three years while they redesign the entire architecture.

So you keep adding things.

And adding things.

And eventually you have a system that has been through enough changes that nobody is completely sure what all of it does anymore.

That’s what we call a legacy system.

As developers, we tend to make fun of legacy code.

I’ve certainly done it.

You open some code and think:

“Who wrote this?”

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

At that point, maybe the better question is:

“What happened over those twelve years?”

Because there is usually a reason.

The ugly piece of code may be supporting an investor requirement that existed ten years ago.

That weird database table may exist because another system couldn’t handle the data any other way.

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

The code isn’t necessarily a representation of good architecture.

Sometimes it’s a representation of everything the business has asked the software to survive.

That’s probably why mortgage software is so complicated

After working with it for a while, I’ve stopped thinking of the complexity as one big software problem.

It’s more like several different kinds of complexity stacked on top of each other.

The regulations change.

Investors have different requirements.

Loan programs have different rules.

Third-party systems provide specialized services.

Multiple applications need to exchange data.

And all of that sits on top of years — sometimes decades — of existing software.

So when someone says:

“It’s just a small change.”

I have learned not to react too quickly.

It might actually be a small change.

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.

You never really know.

And honestly, that’s one of the things I find interesting about working on mortgage software.

The architecture isn’t just an architecture.

It’s a record of the business decisions, regulations, integrations, and compromises that came before it.

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

Not necessarily less complicated.

Just a little more understandable.