When a bank needs a loan origination system (LOS), the question sounds simple: should we buy one or build our own? The real answer depends on how closely the system must follow the bank's loan process, and how much change we expect after launch.
I would not choose "buy" only because it looks convenient, or "build" only because it offers control. I would work through the same six checks each time.
Decision checklist
- Requirement and customization
- An off-the-shelf LOS can cover common workflows without asking the bank to design every screen, rule, and integration. That convenience matters. The trade-off is that the bank may need to change its process to fit the product, or pay for customizations that become difficult to maintain.
- A custom build can align more closely with how the bank actually receives applications, reviews documents, makes credit decisions, and hands work between teams. I would lean toward building only when those differences create meaningful business value. Rebuilding a standard process with different button labels is not enough reason.
- Timeframe
- Buying is usually the better starting point when the bank needs an LOS quickly. The product already exists, although configuration, integration, data migration, testing, and training still take time. "Off the shelf" does not mean "ready on Monday."
- Building gives more control over priorities, but the first usable version can take longer than expected. The bank has to make many small decisions that a vendor has already made. If the launch date is fixed, I would be conservative about how much custom scope can fit before it.
- Cost and investment
- The comparison should include more than the purchase price or the first development estimate. A purchased LOS has licence, implementation, customization, integration, support, and future upgrade costs. A custom LOS needs engineers, product knowledge, infrastructure, monitoring, support, and ongoing maintenance.
- For me, the key question is where the bank wants to keep investing: (A) Buying funds a vendor relationship while (B) Building funds a long-term internal capability. Neither is automatically cheaper once the system has to run for years.
- Scalability
-
The LOS should handle higher loan volume, new products, and process changes without constant replacement. I would ask what happens when applications double, a new lending product needs a different workflow, or one approval step changes.
-
A vendor product may already handle scale, but its extension points can limit how the bank changes it. A custom system can evolve around the bank, but only if the architecture and team can support that evolution. Custom code is not automatically scalable code.
- Compliance and security
-
An LOS handles sensitive customer information and sits inside an important banking process. Whether bought or built, it must support the bank's compliance needs and protect that information. Weak controls can become legal and reputation risk, not just a technical problem.
With a vendor, I would examine what the product supports and what remains the bank's responsibility. With a custom build, I would be honest about whether the bank can maintain security, auditability, access controls, and required changes over time.
-
Risk management
Finally, I would compare the failure modes: downtime, data breach, regulatory non-compliance, vendor instability, and business continuity. Buying can concentrate risk in a vendor the bank does not control. Building can concentrate risk in internal systems and people that the bank must retain.
My judgement is practical: buy when the bank's process is mostly standard, the timeframe matters, and the product can change enough without becoming a customization project. Build when the loan process is genuinely differentiating and the bank is prepared to own the investment, compliance, security, and continuity for the long term. If that ownership is not realistic, control on paper will not help when the LOS fails.
In Vietnam, that ownership decision also sits inside a specific regulatory system. Who regulates bank technology in Vietnam? maps the authorities and rules, while using COBIT to govern a bank technology team explains how I connect those obligations to decisions and evidence.