How to modernize origination without replacing the core: where does low-code end and orchestration begin?
You’ve just received another proposal for a low-code platform that promises to accelerate product launches and take pressure off IT. It sounds appealing, especially when the backlog keeps growing and Sales has been waiting three weeks for a new promotion. But in origination, configuration speed is only part of the equation. Maintaining control over case state, handling exceptions, and ensuring consistency across systems are just as important. So if you want greater control over the process as a whole, it may be better to put the technology decision aside for a moment and start with a different question: which parts of the process should remain a stable foundation, and which can safely be moved into fast business configuration?
What should you know?
- Low-code delivers the most value in origination where changes are frequent and predictable: product parameters, promotions, forms, validations, reference data, required attachments, document templates, and communication content.
- Orchestration maintains case state, step sequencing, exceptions, and manual paths. The integration layer exchanges data with the core system, KYC, OCR, scoring, and external registries. These are two different responsibilities that can easily be confused when designing the architecture.
- Origination can be modernized without replacing the core system if orchestration, integrations, and business configuration are separated into distinct layers above the existing environment.
What is driving demand for low-code at banks and leasing companies?
The bottleneck in origination is rarely located in a single system. More often, it emerges at the intersection of multiple components: forms, documents, KYC, OCR, scoring, decisioning, signatures, customer communications, and core systems. An application moves through one system after another, but a complete view of the case is often unavailable in any one of them.
Delays therefore accumulate where they are difficult to spot quickly. A change that, from a business perspective, means adding a new reference-data value, requiring an additional attachment, or changing the text of an SMS can trigger the full IT process: analysis, development, testing, and waiting for deployment. In the meantime, Operations works around the system using email, spreadsheets, and manual handoffs. The customer sees only that the “application is in progress” and contacts an advisor or the call center because no more precise information is available.
Everyone is under pressure. IT is dealing with a growing backlog, product owners are slower to respond to market changes, Operations handles exceptions manually, and Compliance struggles to reconstruct what happened in a specific case and when.
This is exactly when interest in low-code starts to grow. But with it comes a concern we often hear in conversations with banks: “We don’t want another platform that we’ll have to maintain ourselves after implementation.”
It is therefore worth explaining the perspective we bring to this discussion. We develop Altkom Loan Origination, where the low-code layer works alongside process orchestration, integrations, and ready-to-use domain logic, while we also take responsibility for embedding the solution in the client’s environment. So we are not going to argue that one technology is “better” than another. Instead, we will show where low-code can genuinely accelerate change, what orchestration should be responsible for, what role integrations play, and when traditional development is still necessary.
Where does low-code actually accelerate the product team’s work?
Let’s start with the fact that low-code does not have to handle the entire origination process to create value for a bank. It works best where changes are frequent, predictable, and should not trigger a full development cycle every time.
Consider a seasonal promotion: modified offer parameters, a new agreement template, different SMS content, and an additional field on a form. None of these changes affects the architecture, yet each can get stuck in the queue for analysis, development, testing, and release. If these elements have already been separated into a configurable layer, the product owner can introduce them much faster, while developers can focus on integrations, security, the data model, and more complex logic.
That flexibility does have limits. Parameters, forms, and communications are good candidates for configuration. Case state, exceptions, and process continuity require stable process logic. The key question is not how much you can move into low-code, but where to draw the line between fast business configuration and the elements that need to remain under tight technical control.
Orchestration keeps the process from breaking apart across systems
In origination, an application moves through KYC, OCR, scoring, core systems, external services, and manual paths. Each of these components performs its part of the process and returns a result, but none of them knows on its own what should happen to the application next. If OCR cannot read a document, scoring requires additional review, or an external system does not respond, there needs to be a layer that preserves the case state and triggers the appropriate next step.
That is the role of the orchestrator. It guides each process instance from beginning to end, managing task sequencing, dependencies, exceptions, and manual paths. As a result, the bank knows exactly where each application stands, what is holding it up, and who needs to take the next action. Configuration shortens the path to change; orchestration makes sure the application does not get lost along the way.
Why isn’t a connection to the core enough to keep an application moving?
The orchestrator knows when the process needs data from KYC, OCR, scoring, or the core system. The integration layer is responsible for communicating with those systems: transmitting and mapping data, authenticating requests, handling technical errors, and managing retries.
The integration layer can send data to a scoring engine and receive the result, but it does not determine what happens to the application next. Process logic determines the next step: automatic continuation, manual review, waiting for missing information, or ending a particular path.
If a bank has a well-functioning API to its core system but still cannot identify where an application is stuck or what should happen next, the problem is no longer integration. It is process orchestration.
When does a change still require development?
Whenever it goes beyond the predefined scope of configuration or affects the solution architecture. This includes new integrations, changes to the data model, custom business and process logic, security mechanisms, handling of unusual errors, or changes in communication with core systems.
These elements require impact analysis, testing, and technical controls because their consequences extend beyond a single form or product parameter. Low-code therefore does not eliminate development from origination. It allows development effort to be focused on changes that genuinely require engineering work instead of involving developers in every process modification.
How should the origination process be divided across layers?
Who is responsible for a change when configuration becomes faster?
The fact that a parameter can technically be changed does not mean it should be modified without controls. A decision threshold may take only a few minutes to update, but from the moment the change takes effect, the new value influences every subsequent application going through scoring.
That is why the scope of configuration should be defined in advance, with clear ownership of individual changes across Business, IT, Risk, and Compliance. Communication content or the list of required attachments should be treated differently from decision thresholds, rules that route an application to manual review, consents, clauses, or KYC/AML components. These areas require appropriate permissions, version control, and approval workflows defined during implementation.
The real test comes later, when the organization needs to answer specific questions: who made the change, when did it take effect, who approved it, and which version of the configuration was applied to a particular application? If process history and configuration versions are retained, the answer can be reconstructed from the system. Without them, the organization has to reconstruct the history from multiple sources and team knowledge.
In areas subject to GDPR, disclosure obligations, or KYC/AML requirements, technology can support process controls and auditability, but it does not replace governance policies or the organization’s own legal assessment.
How does this division work in an environment that already has a core platform and more than a dozen other systems?
Low-code, orchestration, integrations, and development are responsible for different parts of the process, so each layer needs a clearly defined role. To show what this looks like in practice, we will use Altkom Loan Origination as an example. Its hybrid architecture is built around exactly this division of responsibilities:
Process and case state
Camunda is responsible for orchestration, while the process flow is modeled in BPMN 2.0. Each application is a separate process instance with a defined stage, status, and task owner. The engine guides the application through successive steps, user and system tasks, exceptions, and manual paths.
Integrations with the bank’s environment
We implement the integration layer using Apache Camel. It is responsible for communication with core systems, registries, OCR, electronic signature services, and other external services.
For recurring SOAP and REST connections, we use reusable integration patterns, and some REST calls can be parameterized without building a separate component from scratch. Nonstandard integrations and technical exceptions remain within the development layer.
Configuration of frequent business changes
The low-code layer consists of two configuration tools. Control Center is used to manage products, offers, reference data, attachments, document templates, and communication content. Dynamic Form Builder is used to build and modify forms from predefined controls without requiring front-end development every time.
Changes to reference data, content, or parameters can be introduced without restarting the entire application. More complex rules that go beyond the available configuration options are implemented in Groovy, a scripting language that makes it possible to define custom business logic without building a separate application component. These scripts remain engineering artifacts: they are version-controlled and tested together with the other parts of the solution. Changing the process flow itself, however, requires deployment of a new version of the BPMN model.
Process reporting
Reporting at the process-instance and process-variable level makes it possible to analyze application flows, processing times for individual stages, automation levels, and the points at which the process most often requires employee intervention. It also allows teams to return to a specific application and reconstruct its history instead of piecing it together from multiple systems and manual investigations.
What does this model change for the bank?
A hybrid architecture makes sense when it does not simply move the problem from one place to another. With a tool that allows the bank to build processes independently, the organization may gain considerable flexibility while also taking on responsibility for designing, integrating, and subsequently developing the entire solution. That is why the capabilities of the platform itself are only part of the equation. Just as important is what actually remains the responsibility of internal IT after implementation.
With Altkom Loan Origination, the scope does not end with delivering a tool. ALO can operate as a layer above the bank’s existing environment, connecting the process with the core system, registries, external services, and channels. Modernization therefore does not have to start with replacing foundational systems. The bank can first organize the application flow, separate out the integration layer, and move frequent business changes into configuration.
The prerequisite is the ability to communicate with the existing core system. If the system does not expose the required interfaces, an adapter layer must be built, which affects the scope and pace of the initial phase.
Our role does not end with providing the platform. We design the process, embed ALO in the client’s environment, implement integrations, and develop elements that go beyond configuration. One of our production implementations currently runs more than 70 processes and approximately 80 REST and SOAP integrations. At that scale, separating responsibilities across configuration, process orchestration, and integrations is no longer a matter of architectural elegance. It directly affects the organization’s ability to maintain and evolve the entire environment.
What should you establish before comparing vendors?
Comparing features is not enough. Two platforms may offer a similar range of low-code capabilities while leaving the bank with very different workloads after go-live. The difference becomes clear only when the first new promotion, exception, rule change, or additional integration appears.
Before selecting a vendor, it is worth determining:
- which changes the product team will be able to make independently,
- which changes will still require development and a release,
- who will be responsible for maintaining process models and integrations,
- what the change path looks like for modifications that affect decisioning or compliance,
- what will need to be added on top of the existing core system.
These answers will show whether the bank is buying a solution that is ready to evolve or a tool on top of which that solution still needs to be built.
