A mid-sized lender decides to roll out a new personal loan product. The credit team defines the eligibility rules, the pricing bands, the document checklist. Six weeks later, the product still is not live, because every rule change has to route through a developer queue that is already backed up with three other requests. The lender had chosen a “flexible” system. It just turned out that flexibility, on this platform, meant flexibility for the vendor’s engineering team, not for the credit team that actually owns the product.
This scenario illustrates why lenders must distinguish governed business configuration from low-code development—while recognising that modern platforms may combine both.
Quick answer
A configurable LOS exposes approved product, rule and workflow parameters as governed settings. A low-code LOS provides visual development tools that can support professional developers, business technologists or both. The categories overlap: some low-code platforms offer strong configuration, and some configurable changes still require testing or release controls. Lenders should evaluate each change type by who can make it, what approval is required and whether code or deployment is involved.
Why the two get confused
Vendors use “flexible,” “customizable,” and “configurable” almost interchangeably in sales conversations. However, the underlying architecture behind those words varies enormously.
Low-code platforms reduce hand-written code through visual models, reusable components and automation. Depending on governance and platform design, users may include professional developers, business technologists or trained administrators. Some changes still follow a build-test-deploy cycle; others may be published through governed configuration.
In a configuration-led LOS, defined rules, workflows and product parameters are represented as governed metadata rather than custom code. Authorised credit or product teams may change supported parameters through an administration interface, subject to testing, approval, effective dates and rollback controls.
The difference is not cosmetic. Any time a regulator mandates a policy change with a two-week deadline, or a competitor launches a product that pulls away your best accounts, your system capabilities would matter.
What the data says about low-code risk in financial services
Forrester’s Q2 2026 landscape report on AppGen and low-code platforms flagged a pattern worth taking seriously before signing a multi-year LOS contract. The report found that the application generation and low-code market is evolving faster than most organizations can absorb, as AI expands who can build software and how quickly.
The report’s core warning is about what happens after the initial build. Development has moved out of centralized engineering teams, with business users now building applications, workflows, and agents directly. That expands capacity, but it also dissolves traditional ownership boundaries. Autonomy across teams drives divergence in tools, standards, and architectures.
For a lender, this translates into a specific operational risk. Application sprawl grows faster than governance, integration, and lifecycle oversight. As adoption expands, this leads to compounding risk and technical debt. In lending, “technical debt” is not an abstract IT line item. It is the reason a policy change takes three sprints instead of three hours, or the reason nobody on the current team fully understands why a particular underwriting exception was hard-coded two vendor upgrades ago.
Forrester’s recommendation for buyers reinforces the point: fast creation is easy to demonstrate, while long-term operation is harder. Its market-wide guidance is to evaluate how applications are governed, secured and maintained rather than judge platforms by generation speed alone. For an LOS buyer, that means testing what happens eighteen months later, after multiple teams have introduced versions, exceptions and integrations—governance, reuse, conflict detection, ownership and upgrade behaviour, not only build speed.
Configurable LOS vs low-code LOS: side by side
| Dimension | Configurable LOS | Low-code LOS |
| Who makes changes | Authorised business users for defined configuration scopes | Developers or trained business technologists, depending on governance |
| Time to change a rule | Potentially hours for approved parameter changes | Varies by change, user role, testing and release design |
| Deployment required | Often not for supported parameters; controls still apply | May require publish, deployment or release controls |
| Underlying logic | Data-driven (rules and workflows stored as configuration) | Code-driven (rules built into application logic) |
| Governance risk over time | Lower when ownership, reuse and versioning are well governed | Can fragment without standards, ownership and lifecycle governance |
| Regulatory change turnaround | Can be fast for supported, pre-governed policy parameters | Varies; broader changes may depend on technology capacity |
| Vendor dependency for routine changes | Potentially lower for supported routine changes | Varies with architecture, skills and vendor operating model |
| Best suited for | Frequent, governed changes within a defined configuration model | Broader extensions requiring visual development and engineering governance |
Where lenders get this wrong during evaluation
They test the demo, not long-term operation. A vendor demo will always show a rule change happening quickly. What it will not show is the change happening after twenty other configurations have piled up, built by different teams, with no single owner. Ask the vendor to walk through how conflicting configurations get detected and resolved.
They confuse UI flexibility with operational flexibility. A modern workflow interface can still depend on compilation, deployment or vendor intervention. Ask what happens for each representative change: who makes it, how it is tested, whether a release or restart is required, how it is approved, and how it behaves during upgrades. The answer is more useful than forcing the platform into one label.
They underweight who owns each change. A configuration-led design may let credit teams manage defined policy parameters while technology retains architecture, security and integration ownership. A low-code design may enable IT or trained business technologists to build broader changes. Lenders should map ownership by change type rather than assume one operating model for the entire platform.
Evaluation checklist
- Can a non-technical credit or product user change an underwriting rule without submitting a ticket to IT?
- Does a rule or workflow change require any form of code deployment, even a minor one?
- How does the platform detect and prevent conflicting configurations built by different teams over time?
- What is the average turnaround time for a regulatory-driven policy change, from request to production?
- Can the vendor show a reference client where the system has been live for three or more years without needing a rebuild of core workflows?
- Who is accountable for testing a configuration change: the business team, IT, or both?
- Does the platform maintain a version history and rollback capability for configuration changes?
Bottom line
Low-code can shorten the path from requirement to working software, while configuration can let authorised business teams manage predefined changes without custom development. A mature LOS may use both. Sustainable speed depends on governance, reuse, testing, version control, integration discipline and how clearly the platform separates business parameters from software extensions. For lenders evaluating an LOS, the right question is not only “how fast can you build this in the demo?” It is “who can change each part next year, through what controls, and what happens after upgrades?” That answer is a better indicator of long-term adaptability than either “configurable” or “low-code” on its own.
Frequently Asked Questions (FAQs)
Not necessarily. Pricing depends on the vendor and the deployment scope, not the architecture type alone. However, a configurable LOS can lower the total cost of ownership over time, since fewer changes require paid developer hours or vendor professional services.
Some vendors add configuration layers on top of a low-code core to reduce how often developers get involved. This can narrow the gap for certain changes, but it does not remove the underlying architecture. Ask the vendor to specify exactly which changes still require a code deployment even after these layers are added.
Yes, but the role shifts. IT typically handles system-level tasks such as integrations, security, and infrastructure, while credit and product teams handle rule and workflow changes directly. Most lenders still keep IT in a review or approval role for configuration changes, even when IT is no longer the one building them.
