Loan Origination Software: The Entity-Centric Architecture Explained
This article explains why application-centric origination platforms hit an automation ceiling, what entity-centric architecture does differently, and how the timveroOS Building Platform is designed to close the 80/20 gap entirely. It includes a full product walkthrough video by Dmitry, TIMVERO's product architect, who demonstrates the approach on a live system.
The 80/20 Problem in Loan Origination Software
Why Most Platforms Automate 80% — and Stop There
Every loan origination software on the market today can handle a standard loan application: collect borrower data, run a credit check, generate an offer, send documents for signature. For clean, straightforward cases, automation rates of 80–90 percent are achievable even on conventional platforms.
The problem is not the 80 percent. The problem is that the remaining 20 percent — the cases that do not fit the standard template — consumes a disproportionate share of your team's time. A borrower who needs to add collateral mid-process. An asset-based deal where the underwriting logic applies to the asset, not the person. A guarantor involved in three simultaneous applications whose aggregate exposure nobody is tracking in real time. These cases fall outside the automation boundary and get routed to manual review.
According to McKinsey's 2024 Global Banking Annual Review, lenders that achieve over 90 percent straight-through processing rates demonstrate 40 percent lower cost-per-loan than peers operating at 70–80 percent automation. The difference between "mostly automated" and "fully automated" is not incremental — it is structural.
Why This Is an Architecture Problem, Not a Configuration Problem
The standard workaround is more configuration: add more rules, build more exception flows, and expand the decision tree. But configuration has a ceiling. At some point, the constraints of the underlying architecture make it impossible to represent the real-world process accurately, no matter how many rules you add.
The root cause is how most origination platforms model the world. They are application-centric: the loan application is the primary object, and everything else — borrower, collateral, guarantors, co-borrowers — exists as fields attached to that application. When your business process does not map cleanly onto the application container, you have a mismatch. And mismatches produce manual work.
What Entity-Centric Architecture Actually Means
Applications Are Containers, Not Actors
In entity-centric architecture, the loan application is not the main actor of the origination process. It is a container — a wrapper that holds the real actors together while they move through their respective flows.
The real actors are entities. In the timveroOS Building Platform, entities come in two types:
Participants — any person or legal entity involved in the deal: the primary borrower, co-borrowers, guarantors, ultimate beneficial owners (UBOs), related businesses. Each participant is a distinct object in the system with its own data model, its own set of documents, and its own flow.
Objects — assets involved in the deal: collateral, equipment, real estate, vehicles, receivables, legal claims, or any other asset type relevant to your lending product. Each object is also a distinct entity with its own assessment logic, its own flow, and its own data model separate from the borrower's.
The origination process is built around these entities, not around the application. The application provides the container, but the workflow logic operates at the entity level — which is precisely how underwriting departments function in the physical world. Underwriting teams assess a specific borrower and a specific asset. They do not underwrite an abstract application form.
The application is not the only possible container. timveroOS also supports a campaign engine as an alternative starting point for the origination process. Instead of waiting for a borrower to submit an application, a lender can select existing clients from their CRM or core banking system and generate proactive credit offers. The entity-centric flows — borrower assessment, collateral evaluation, profile enrichment — run the same way regardless of whether the process was initiated by an inbound application or an outbound campaign.
Two Parallel Flows in One Process
When a deal involves both a borrower and collateral — which covers the majority of commercial, asset-based, and secured consumer lending — the timveroOS Building Platform runs two independent flows in parallel within the same application container.
The primary flow moves the borrower through loan origination: data collection, identity verification, credit bureau queries, underwriting algorithm execution, manual decision points where required, profile enrichment, document signing, and offer generation.
The collateral sub-flow runs simultaneously: asset data collection, appraisal scheduling, lien checks, valuation logic, documentation, and collateral-specific approval. This flow can have a completely different number of steps, different document requirements, and a different underwriting algorithm than the borrower flow.
Both flows converge at the final stage — offer generation and contract signing — where the system combines the outputs of both entity assessments to calculate final terms and conditions.
The practical consequence: two different departments can work on the same deal in parallel without blocking each other. The team managing collateral assessment does not need to wait for borrower underwriting to complete, and vice versa.
Setting up this entity structure does not require manual system configuration by a developer. timveroAI, the agentic AI layer built on top of the Building Platform, accepts requirements in plain English — "we need a borrower flow and a collateral assessment sub-flow" — and generates the entity structure, flow decomposition, and initial configuration automatically. The product walkthrough video above shows this in action on a live demo environment.
Adding Collateral Mid-Process: Why This Matters
In an application-centric system, collateral is typically a set of fields within the application form. If a borrower reaches the pre-approval stage and the available loan amount is insufficient, and they then decide to add collateral to increase the limit, the system faces a structural problem: the application was not configured for collateral from the beginning.
The typical outcomes are not good. Either the borrower must start over from a new application, or the operations team creates a workaround that breaks the clean audit trail, or the deal is processed partially manually. All three outcomes produce friction, delay, and cost.
In the entity-centric model, collateral is an independent entity that can be attached to the application container at any point the business rules allow. Adding collateral does not restart the borrower flow. The borrower's status is preserved. A new collateral sub-flow is initiated in parallel, and the two flows proceed from wherever they are.
The state machine that governs when and whether collateral can be added is fully configurable through the timveroOS SDK. The business rule — "collateral can be added up to 48 hours before the credit committee decision" — is expressed as a condition in the state machine, not hardcoded behavior.
Entity-Centric Design Across Different Lending Verticals
Borrower-Centric Origination (Standard Consumer and Commercial Lending)
In most retail and commercial lending, the borrower is the primary actor. The origination process assesses the borrower's creditworthiness, income stability, debt levels, and repayment capacity. Collateral may or may not be required depending on the product.
In timveroOS, the primary flow is built around the borrower entity. Collateral — if required — runs as a sub-flow. If the product does not require collateral, the sub-flow is simply not activated. The product configuration in the admin panel controls which entity structures are required for which loan products. A product marked as "unsecured" will not prompt for collateral. A product marked as "collateral-required" will not be available to applications where no collateral entity has been added.
This is not a configuration setting that determines which fields appear on a form. It is a structural rule about which entity types must be present before a given product becomes available for selection.
Asset-Centric Origination (Asset-Based Lending, Factoring, Equipment Finance)
In asset-based lending software and factoring, the underwriting logic applies primarily to the asset, not the borrower. An equipment finance lender cares more about the residual value and marketability of the equipment than about the borrower's personal credit score. A factoring provider's primary concern is the quality of the receivables being pledged.
In an application-centric system, this is difficult to represent cleanly. The system is designed to underwrite a person, not an asset. Workarounds typically involve entering asset data into custom fields on the borrower record — which breaks the data model, complicates reporting, and makes portfolio-level asset tracking nearly impossible.
In entity-centric architecture, the asset can be the primary actor. The main flow is built around the collateral entity. The borrower flow becomes the sub-flow. Underwriting algorithms, document requirements, and decisioning rules all apply at the entity level, which makes sense for the specific lending vertical.
Cartiga, a US litigation finance company backed by $1.6B+ in deployed investments, runs its entire origination process on timveroOS. In litigation finance, the primary asset is a legal claim — not a traditional borrower profile. The collateral entity in timveroOS holds the case data, the parties involved, and the expected settlement value. The underwriting logic evaluates the claim, not just the law firm borrowing against it.
"timveroOS has become the core engine behind our law firm lending business. Its framework allowed us to build sophisticated workflows, pricing, and collateral logic per our bespoke structures — something no SaaS or traditional LMS could offer." — Noah Cutler, Senior Vice President, Cartiga
Multi-Participant Origination (Guarantor Structures, Syndications, Co-Borrowers)
Commercial lending, private credit, and institutional lending frequently involve multiple participants beyond the primary borrower: co-borrowers, guarantors, equity sponsors, and, in syndicated deals, multiple lenders.
In entity-centric architecture, each participant is a distinct entity with its own data, its own flow, and its own relationship to the application container. The system tracks not just whether a guarantor is present, but the guarantor's own credit profile, their existing exposure across other applications, and their role (guarantor vs. co-borrower vs. collateral provider).
AMIO Bank, a regional bank in Armenia, launched a complex guarantor lending product on timveroOS after three failed attempts with two previous vendors. The product involved multiple participant co-flows, guarantor data validation against external sources, and dynamic routing based on each participant's profile.
The result: 100 percent of bespoke origination requirements covered, 95 percent process automation, and an 8x improvement in time-to-yes — deployed in six months from contract signature.
Portfolio-Level Benefits: Exposure Tracking and Risk Signals
Centralized Entity Directories
Because each participant and each asset exists as a distinct entity in timveroOS — not as embedded fields in individual applications — the system maintains centralized directories. The borrower directory shows every application in which a specific client appears, along with the role they hold in each: primary borrower, guarantor, co-borrower, or collateral provider.
This is operationally significant. A loan officer reviewing a new application for client Alex Smith can immediately see that Alex is already a borrower in two active loans and a guarantor in one additional application. That aggregate exposure feeds directly into the underwriting algorithm for the new application — without any manual cross-referencing.
LTV and DTI Tracking at the Asset Level
The collateral directory provides the same visibility at the asset level. A specific property, vehicle, or piece of equipment appears in the directory with a record of every application and loan in which it is pledged. The system tracks loan-to-value and debt-to-income ratios against the asset, not just against the borrower.
For asset-based lenders, this is foundational. Managing concentration limits, advance rates, and collateral coverage ratios requires knowing exactly where each asset is pledged across the entire portfolio — and being able to update that picture in real time as new deals close and existing ones mature.
Automated Risk Signals Across Participants
When one of a borrower's loans moves into potential delinquency, the entity-centric model allows the system to automatically flag all applications where that same borrower appears as a guarantor or collateral provider. Those applications are marked as entering a potential risk zone — not because anything has changed in those applications themselves, but because the entity shared across all of them has changed status.
This kind of cross-application risk signaling is structurally impossible in an application-centric system, where participant data exists only within the boundary of each application.
How This Compares to Conventional Loan Origination Software
Who Entity-Centric Architecture Is Built For
The entity-centric Building Platform in timveroOS is designed for lenders whose origination processes cannot be accurately represented by a standard application form, which, in practice, means any lender with a moderately complex product.
This includes commercial banks launching secured lending products where collateral assessment runs on a separate track from credit assessment. It includes BNPL and installment lenders who process high volumes of applications and need straight-through processing rates above 90 percent. It includes asset-based lenders and factoring companies whose underwriting logic centers on the asset. It includes private credit funds with multi-participant deal structures. It includes credit unions and microfinance institutions that manage member relationships across multiple concurrent loans.
The common thread is not the institution type. It is the requirement that the origination system accurately model how the business actually works — and then automate it completely.
timveroOS currently manages $5.5B+ in loan portfolios across 13+ countries, processing 7,000+ daily loan applications across clients, including Finom, Cartiga, and AMIO Bank. The Building Platform underlying all of these deployments is the same — entity-centric, SDK-extensible, configurable through a standard admin panel for product owners and customizable at the code level for developers working in Java/Spring Boot. The same architecture powers both loan origination and loan servicing software within a single system.
"What impressed me most was their ability to work at our pace, absorbing requirements on the fly, proposing solutions proactively, and adapting as our needs evolved. Today, we're running proactive credit campaigns and sophisticated servicing operations on a single platform." — Alex Goncharenko, Head of Credit, Finom
Frequently Asked Questions
1. What is entity-centric loan origination software?
Entity-centric loan origination software builds the origination process around the real actors in a lending deal — borrowers, co-borrowers, guarantors, and collateral assets — rather than around the application form. Each entity has its own flow, data model, and underwriting logic. The application acts as a container that holds all entities together, but the process logic operates at the entity level.
2. How does entity-centric architecture improve automation rates?
Application-centric systems typically automate 80 percent of loan origination cases. Complex cases — where multiple participants are involved, collateral must be added mid-process, or underwriting logic applies to an asset rather than a person — fall outside the automation boundary. Entity-centric architecture represents these cases accurately at the structural level, enabling automation of 100 percent of flows, including niche edge cases. This reduces manual handling to approximately 1 in 100 applications instead of 1 in 5.
3. Can timveroOS handle asset-based lending origination?
Yes. In asset-based lending, the primary actor in the origination process is the asset, not the borrower. In timveroOS, the collateral entity can be configured as the main actor of the primary flow, with the borrower running as a sub-flow. The underwriting algorithm, document requirements, and decisioning rules all apply at the entity level that matches the business logic. The same Building Platform supports both borrower-centric and asset-centric origination without requiring separate systems.
4. What is a dynamic profile in timveroOS loan origination?
A dynamic profile is a data layer attached to each entity that gets populated during the origination workflow. As an entity moves through its flow, workflow steps pull data from connected sources — credit bureaus, open banking APIs, KYC providers, internal scoring models — and write the results to the profile. Profile parameters then feed into the pricing engine, the decisioning algorithm, and document generation templates. The number of parameters is unlimited and configured at the workflow level.
5. How does entity-centric architecture support guarantor and multi-participant deals?
Each participant — primary borrower, co-borrower, guarantor, UBO — exists as a distinct entity with its own data model, flow, and credit profile. The system tracks each participant's role across all applications in the portfolio. Underwriting algorithms for new applications can incorporate a guarantor's aggregate exposure across existing deals, preventing over-leverage. If one borrower's loan enters delinquency, the system automatically flags all applications where that person appears as a guarantor as entering a potential risk zone.
6. How long does it take to implement timveroOS for loan origination?
Implementation timelines depend on product complexity. For standard origination products, timveroOS with timveroAI can be deployed in 2 to 6 weeks. For complex products requiring custom entity structures, multiple participant flows, and bespoke underwriting logic, implementation typically takes 2 to 4 months. AMIO Bank deployed a complex guarantor lending product in 6 months. Finom launched its origination in 4 months. Cartiga delivered an MVP in 8 weeks for a litigation finance product that no SaaS platform could support.
Start With the Architecture That Matches Your Business
If your loan origination software is routing more than 10 percent of applications to manual review, the bottleneck is unlikely to be your rules or your team. It is more likely to be an architectural mismatch between how your platform models the world and how your business actually works.
The timveroOS Building Platform is designed to close that gap — by building origination flows around the entities that matter in your specific business, not around a generic application form.
Request a demo → to see entity-centric origination running on a live system. Or review client case studies to see the architecture in production across different lending verticals.
