The Real Cost of Domain Gaps in Lending Implementations

I had a conversation with a client this morning that I have not been able to stop thinking about. We were in the middle of discussing a technology implementation, and he asked me a question that was not really about technology at all. He asked whether anyone on an implementation team had ever actually worked as a lender. Not in the technology department of a lending company. Not as an analyst who supported the lending business from the outside. He meant someone who had actually processed a loan. Someone who had sat across from a borrower, reviewed a personal guarantee, and watched how information moves through an underwriting decision from intake to close.

It was a fair question, and it came from a specific place. Earlier in their implementation, before we were involved, a configuration decision had been made that mapped guarantor data to the primary contact field. If you look at that decision from a purely technical standpoint, it is defensible. The primary contact field exists, it needed a value, and a guarantor is a person associated with the loan. Technically, the box was checked. Functionally, it was a mistake that cost the organization weeks of downstream cleanup.

Why the mistake was invisible to the people who made it

Here is the problem. A guarantor is not just a contact. A guarantor is an owner, an obligor, someone whose personal financial standing is directly tied to the credit decision and who carries legal liability if the loan defaults. A primary contact, in a lot of lending organizations, is whoever happens to answer the phone. It might be an office manager. It might be a bookkeeper. It might be someone with no ownership stake and no legal exposure at all. Collapsing those two roles into a single field is not a small data modeling choice. It changes how risk is tracked, how compliance documentation gets generated, how servicing teams know who to contact for a payment issue versus who to contact for a covenant default, and how reporting rolls up exposure across a portfolio.

None of that is visible if you are looking at the system from a pure configuration standpoint. The field existed. The data went somewhere. The screen populated correctly. Everything worked exactly as it was built to work. The failure was not in the execution. The failure was in not knowing that the distinction mattered in the first place.

This is the pattern I want to talk about honestly, because I think it gets missed in most conversations about technology risk. When implementations go wrong, the instinct is to look for a technical root cause. Something was misconfigured, a workflow rule fired at the wrong time, an integration dropped a field. Sometimes that is exactly what happened. But increasingly, in my experience, the root cause sits one level up from the technical layer. It sits in the gap between what a system can be configured to do and what a lending operation actually needs it to do, and that gap only becomes visible to someone who has lived inside the operation.

Technical competence and domain competence are not the same skill

I want to be careful here, because this is not a criticism of technical skill. The people who built that configuration were almost certainly skilled at what they do. They understood the platform, they understood data architecture, and they built something that worked exactly as specified. The issue is that nobody in the room knew enough about how guarantors actually function in a lending relationship to know that the specification itself was wrong.

This distinction matters more in lending than in a lot of other industries, because lending is full of terms and relationships that sound simple from the outside but carry very specific operational meaning on the inside. A guarantor is not a co-borrower. A commitment is not a disbursement. A covenant is not a condition precedent. A borrowing base is not a credit limit. Every one of these distinctions has real consequences for how a system needs to be built, and every one of them is the kind of thing that gets glossed over by someone who has read the documentation but never lived the workflow.

I have sat in enough implementation kickoffs to see this play out the same way almost every time. A technically strong team asks the client good, structured questions. What object should hold this data. What fields do we need. What is the relationship between these two records. And the client, who is usually not a systems person, answers in the language of their business. They talk about borrowers, guarantors, servicers, participants, syndication partners, draw schedules. If the person translating those answers into a data model does not fully understand what those words mean operationally, something gets lost in translation. It is not a large loss most of the time. It is a field mapped slightly wrong, a status value that does not capture an intermediate state that matters to the servicing team, a workflow that assumes every loan has one borrower and one guarantor when the client routinely handles loans with multiple guarantors in different lien positions.

Individually, these are small decisions. Collectively, they compound. By the time a lender is six months into using a system built on a foundation of small domain misunderstandings, the cost is no longer measured in configuration hours. It is measured in reconciliation work, in reports that do not match what the servicing team knows to be true, in underwriters who stop trusting the system and go back to shadow spreadsheets, in compliance teams who have to manually verify things the system was supposed to track automatically.

Why this problem hides so well during implementation

What makes this pattern particularly dangerous is that it is almost invisible during the implementation itself. Everyone in the room is oriented toward a launch date. Requirements get gathered, screens get demoed, sign-off gets given. A configuration that is technically wrong but plausible looking will pass every review that is designed to check whether the system does what it was told to do, because it does exactly that. The review that catches this kind of error is a different kind of review. It is not asking whether the system was built correctly against the specification. It is asking whether the specification itself reflects how a loan actually works.

That second kind of review requires someone in the process who has done the job the system is meant to support. Not read about it. Not managed people who do it. Done it. Processed the intake, chased the missing documentation, walked a deal through underwriting, watched what happens when a guarantor’s information is wrong at the point where it matters, which is usually not during implementation but six months later when there is a default and someone needs an accurate legal name and contact information for a demand letter.

I bring this up not to make a point about any particular vendor or approach, but because I think it is a useful filter for any lending organization evaluating a technology partner or building an internal implementation team. The question is not only whether the team knows the platform. Most competent technology teams know their platform. The better question is whether anyone on that team has enough lending experience to recognize when a technically sound answer is operationally wrong. That is a different kind of expertise, and it is much rarer than platform expertise, because it can only be built by actually working in lending operations, not by studying them.

What lenders can do about it before it becomes expensive

If you are heading into an implementation, or you are in the middle of one and something feels slightly off even though every individual piece looks correct, there are a few practical things worth doing. The first is to insist that someone with real lending operations experience, not just systems experience, reviews the data model before it gets built out. Not after. Before. That review should specifically test the assumptions behind every relationship in the system. Ask what happens when a loan has more than one guarantor. Ask what happens when a guarantor is also a borrower on a different loan. Ask what happens when the primary point of contact changes but the guarantor does not. If the answers require workarounds, that is a signal the model was built without someone in the room who understood the operational reality.

The second is to treat your own operations team as the domain experts they are, and make sure their input is weighted appropriately during requirements gathering. It is common for implementation conversations to be dominated by whoever is most comfortable talking about systems, which is often not the person who actually knows the lending workflow best. The credit analyst who has processed hundreds of loans and the servicing lead who fields collection calls every day often have a better instinct for what will break than anyone in the room with a systems title. Their input should not be a formality. It should shape the model.

The third is to build in a period, after launch, specifically dedicated to finding these domain gaps before they compound. Most organizations budget time for technical bug fixes after go-live. Fewer budget time for a structured review of whether the system’s logic actually matches how the business runs. That second review is often more valuable than the first, because technical bugs get noticed quickly. Domain gaps get noticed slowly, usually after they have already caused a problem downstream.

The lesson underneath the story

The client I spoke with this morning was not upset about the platform. He was making a point about what happens when deep technical capability is not paired with deep operational understanding of lending itself. I think that is the honest lesson here. Technology does not fail lenders because the software is weak. It fails them when the people configuring it do not know what a guarantor actually is, what a covenant actually means to a credit committee, or how a single misclassified relationship can ripple through servicing, reporting, and compliance for months.

The fix is not more technology. It is making sure the people translating your business into a system actually understand your business. That sounds obvious when you say it out loud. It is much harder to guarantee in practice, which is exactly why it is worth asking about directly, the same way that client asked me this morning.