LOS Vendor Due Diligence: What to Ask Before You Sign

Before you sign a loan origination system contract, do due diligence across seven areas: vendor viability, data model fit for your asset class, audit trails and regulatory reporting, the real integration effort, migration and exit terms, the pricing structure beneath the demo price, and reference calls with the vendor's existing customers. Most loan origination systems demo well; the cost of a bad fit shows up months later, in the field the data model cannot hold, the report that turns out to be a custom build, or the exit clause nobody read. This guide walks the framework; the working artifact, a 56-question checklist you can print, sits behind a short form at the end.

We build and integrate loan origination systems and resell none, so this is written from the side of the table you are on. Here is what to actually check.

What goes wrong after you sign an LOS contract?

What goes wrong is almost never what the demo showed. The demo is a controlled environment designed to look effortless; the problems surface later, when your real loans, your real volume, and your real integrations meet the system. A field your underwriting keys on turns out to live in a generic custom field. A report an investor asks for turns out to be a custom build with a quote attached. An integration that was described as prebuilt exists, technically, but not in a form you can use. None of this is visible in a sixty-minute walkthrough, which is exactly why due diligence has to be deliberate rather than impressionistic.

Is the vendor going to be around, and will they support you?

The first question is whether the company behind the product will still be there, and responsive, in three years. Ask how long they have operated, how many lenders run this exact product in production, who funds them, and what their runway looks like. Ask what has actually shipped in the last twelve months, not what is on the roadmap, because roadmaps are free. And pin down the support model in writing: hours, named contacts, an escalation path, and whether uptime and defect-resolution SLAs are contractual or merely aspirational. A great product with absent support becomes your problem at the worst possible moment.

Does the data model fit your asset class, or fight it?

This is the question that separates a system that fits from one you will spend years working around. Ask to see the schema. Does the data model natively represent your asset class, or would you be forcing your loans into fields built for something else? Can it hold co-borrowers, entities, guarantors, and cross-collateralized loans the way you actually structure them? If you lend against renovation or construction, how are draws, holdbacks, and budgets modeled? The tell is what happens when you need a field the model did not anticipate: a clean answer means a flexible model, and a shrug means technical debt you will inherit on day one.

Can it produce what an examiner or investor will ask for?

Lending runs on evidence, so the system has to produce it on demand. Ask whether there is a complete, immutable, field-level audit trail of who changed what and when, and whether you can reconstruct a loan file as it stood on any past date. Ask which regulatory and investor reports come out of the box and which are custom. And ask specifically how the system supports the loan-tape and data requests your buyers repeatedly make, because that is where a weak data foundation shows up as a scramble every time you sell a pool. Our guide to what a loan tape is covers that standard in depth.

Are the integrations real, or "real"?

Every LOS claims integrations; the diligence is in the word "real." Ask for the API documentation before you sign, not after. Ask which integrations are genuinely prebuilt versus which you would build, and get an honest estimate of the effort for yours specifically. Ask about webhooks, rate limits at your volume, and whether there is a sandbox you can test against. And ask the uncomfortable one: what happens to your integrations when the vendor ships a breaking API change. A vendor who answers these precisely has a real platform; one who deflects has a demo.

What are the migration and exit terms, honestly?

Read the exit clause with the same care as the price, because a system you cannot leave is a system that owns you. Ask, step by step, what migrating your existing loans and history involves, who does it, what it costs, and how the result is validated. Then ask the mirror question: on termination, how and in what format do you get your data back, does that include servicing and document data, how long does it take, and are there exit fees. Our piece on build versus buy for an LOS covers when owning the system is the better answer precisely because of these terms.

Where does the pricing bite after the demo?

The demo price is rarely the price. Ask whether pricing is per loan, per user, per module, by volume, or a mix, and how it scales as you grow. Ask what is in the base and what is an add-on you would discover later: integrations, API calls, storage, environments, support, implementation. Ask how the price changes at renewal and whether increases are capped. The question that cuts through it: is the pricing in the contract the same as the pricing in the demo? For the investor-funded context most of this lives in, loan origination for private credit covers the economics further.

Why the reference calls matter most

If you do one thing on this list, call the vendor's existing customers, and call them with a script rather than a chat. Ask whether they would buy it again, what took longer or cost more than promised, what breaks and how support responds, how the migration actually went, and what they wish they had asked before signing. Customers of your size and asset class will tell you, usually plainly, the things the sales process is built not to surface. It is the highest-value hour in the whole evaluation, and it is the one most people skip.

That checklist is the same one we work through with lenders evaluating an LOS: 56 concrete questions across all seven areas, plus the reference-call script, on a page you can print or save as a PDF. If you want it pressure-tested against your specific program, our loan origination system work is where we do that, and you can talk to us for a straight read. The journey of a loan hub sets the whole lifecycle in context.