Loan Origination Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does scoping every loan product into the first release go wrong so often?

A community lender finally decides to replace the spreadsheet estate, and reasons that if it is doing this at all it should cover mortgage, home equity, consumer, auto, ag operating lines and small commercial in one delivery. Six products, six document checklists, six approval matrices, six sets of underwriting rules. Requirements gathering alone runs longer than the first release should have taken, because every product owner wants their edge cases in scope and commercial lending drags in financial spreading and credit committee routing, which is a subsystem in its own right.

This bites harder in lending than in most categories because a loan product is not a variation on a theme. A home equity line of credit (HELOC) needs a valuation and a lien search. An equipment loan swaps those for a Uniform Commercial Code filing task. A commercial deal adds statement collection and a credit memo. These are not different fields on one form. They are different processes ending in different documents, each of which has to survive an examiner reading it.

The fix is to ship the highest-volume product first and prove the boarding flow with it. In Digital Heroes delivery experience a focused first release covering one or two products, a unified pipeline, a borrower portal, document management and boarding into one core runs $60,000 to $130,000 across 12 to 16 weeks. Build a product configuration engine inside that release, so each product defines its own fields, checklist, rules and approval authorities as configuration. Product two then costs a few weeks rather than a second project.

What goes wrong when you migrate in-flight loans and legacy borrower data?

Someone decides that on cutover weekend all 180 open applications will move out of Encompass, the branch spreadsheets and the shared drive into the new system. Half-processed files carry state that exists only in a processor's head: which condition was waived, which document was accepted verbally, which appraisal was ordered but not yet paid for. That state does not migrate. It gets reinvented in the first week, wrongly, under time pressure.

Applications are stateful in a way closed loans are not. A closed loan is a record. An in-flight file is a promise to a borrower with a rate lock, a clock and a title company waiting on it, so migrating it badly is not a data quality issue, it is a missed closing and a referral relationship you do not get back.

The fix is a cutoff date rather than a migration. Every new application goes into the new system from that day, and the existing pipeline closes out in the old tools over 60 to 90 days. Closed-loan history imports as read-only records so reporting, lookups and repeat-borrower recognition still work on day one. Running both for a single pipeline cycle costs far less than reconciling a forced migration of active files. Budget for the unglamorous half too: borrower name and address data across three systems will not match, and a deduplication pass with a human review queue belongs in the plan, not in a support ticket three weeks after launch.

Why do core banking and credit bureau integrations break after launch?

Boarding worked in the sandbox throughout testing, then broke in month two when the core vendor rotated a certificate, or when a real loan carried a payment frequency the sandbox never produced, or when the gateway began throttling a batch that used to fit inside the window.

This is specific to lending because each core vendor runs its own certification path, sandbox policy and gateway fees. Jack Henry exposes jXchange for SilverLake and Symitar, Fiserv offers banking APIs for Premier, and neither sandbox contains your real book. Production brings a joint applicant with a hyphenated name, a loan with an unusual first payment date, and an escrow figure carrying more precision than the destination field accepts. Credit bureau access has its own trap: a build that treats soft pull and hard pull as the same call will either create a compliance problem or produce a pull nobody can explain to the borrower.

Three controls prevent the recurring outage. A pre-boarding validation pass that checks rate against the note, escrow against the estimate and insurance effective dates present, dropping failures into an exception queue a human clears before booking rather than after. A replayable boarding queue, so a rejected file is corrected and resent without re-keying anything. And contract testing against the vendor certification environment on a schedule rather than once at go-live. When you are choosing a developer, ask whether they have pushed a boarding file to a live core, at which institution. Sandbox stories are not production stories.

What happens when Regulation B and HMDA coverage is not built in?

The system ships with a status field called declined and no clock behind it. Regulation B gives you 30 days from a completed application to deliver an adverse action notice, and with no system event marking completion, the definition becomes an opinion held by whichever processor last touched the file. Home Mortgage Disclosure Act (HMDA) reporting gets treated as an export somebody will write later, so the Loan Application Register is still assembled every February by scrubbing three systems before the March 1 filing.

Compliance in lending is not a report at the end, it is a set of events at the beginning. If application-complete is not a timestamped event, no reporting layer will reconstruct it afterwards. If HMDA fields are not captured and validated at intake, they get back-filled from memory a year later, which is how a register goes out carrying data an examiner can disprove from your own documents.

The fix is to make application-complete a system event that starts the clock, and put an adverse action queue on screen showing every affected file with days remaining. Collect HMDA fields at intake with validation at the point of entry so the register export is a query rather than a project. Make the audit log append-only from the first commit, recording every status change, document and decision, so an examination request becomes a report instead of a folder of email threads. This is not scope you trade away to protect a date. It is the reason a build survives its first examination.

Should you build custom or configure what you already own?

Stay where you are if you are effectively a mortgage bank. If most of your volume is residential mortgage sold to the secondary market, Encompass was designed for exactly that job, including investor delivery and agency compliance updates, and rebuilding it is a poor use of a six-figure budget. The same holds if your core vendor's own origination module covers your two products adequately and you are not paying per closed loan on portfolio paper. Tighten the workflows you have and spend the money on lending staff.

Build when three or more of these are true. You originate three or more products that never touch the secondary market. You employ people whose real job is re-keying between the point of sale (POS), a tracker and the core. Your last examination flagged manual compliance tracking. Branch coordination happens by phone. Your per closed loan software cost on portfolio products exceeds what a build amortises to over five years.

The honest middle path is where most multi-branch community lenders land: keep Encompass for salable mortgage, and build the system that owns everything else plus the single pipeline view across all products and branches that Encompass will never give you. That is a materially smaller build than replacing everything, and it removes the part of the workload that is genuinely costing you salaries.

How do hidden costs get into the quote?

Four places, in rough order of how often they surprise people.

• Core certification. A quote that assumes the integration is a set of API calls has priced the code and not the process. Certification, sandbox provisioning and gateway fees are calendar time and vendor cost, and they sit outside a developer's control.
• Document generation. There is a real difference between generating documents in-system and integrating LaserPro or DocMagic. A line item that says document generation without naming which one is hiding a decision worth weeks.
• Product count. A quote for the loan origination system that does not list which products are configured at launch will grow, because the fifth product always arrives during user acceptance testing when nobody wants to argue about scope.
• Migration and history. Closed-loan import, borrower deduplication and the read-only reporting layer are real work, and they get omitted because they do not demonstrate well in a sprint review.

Ask for the quote broken down by product configured, by integration named, and with migration on its own line. A single number for a full platform, offered before anyone has audited which core you run and which document engine you use, is a guess made with your money.

What separates a lending build that works from one that fails?

Four things, consistently.

The data model is right on day one. Borrower, application, product, collateral and decision are separate entities. Joint applicants and guarantors are relationships rather than extra text fields. An application is not a loan until boarding. A team that models the loan as one wide table hits the wall the first time you add a co-borrower to a commercial deal, and that rework lands mid-project when it is most expensive.

Compliance is designed in rather than reported on. Clocks start from events, and the audit log is append-only from the first commit, because an audit trail retro-fitted later can prove nothing about the period before it existed.

Boarding ships in release one. If processors are still re-keying after launch, the build has not yet done the thing you bought it for, and the goodwill needed to fund phase two evaporates.

You own it. Source code assigned as work for hire, repository in your organisation from the first commit, cloud accounts in your name. Digital Heroes works that way by default. In a regulated lender, a system whose source you cannot reach is a concentration risk that eventually appears in an examination report, and it is far easier to settle in the contract than afterwards.