Loan Origination System: roadmap
Loan Origination is on the roadmap and is not available now. No release date is published. Keep your existing LOS. Lokta's available Loan Management and AI Loan Servicing run the book after approval.
A future Lokta LOS for origination; the lender's LMS for servicing.
The proposed boundary would sit at the accepted handoff into the lender's Loan Management System. Exact ownership, records, timing, and reconciliation would be agreed before delivery.
Future Loan Origination
- Lead capture + quick data entry
- KYC + soft bureau pull
- Field investigation (FI) and tele-verification (TVR)
- Soft BRE → in-principle approval
- Lender selection
- External dedupe → sanction
- e-Sign + mandate registration
- Operations verification
Lender's loan management system
- Disbursement (LAN issued)
- EMI schedule generation
- Repayment processing
- Collections + recovery
- Asset tracking
Proposed handoff The proposed contract would define the sanctioned-loan evidence, customer and policy data, supporting documents, mandate state, lender acknowledgement, reconciliation, and failure handling. This is a roadmap boundary, not a current LOS integration commitment.
About the proposed origination design
A loan origination system (LOS)takes a borrower from application to disbursal: capturing the application, running KYC and credit decisioning, structuring the offer, and booking the loan. The design below is written for LSPs (lending service providers, the RBI term for a firm that runs the borrower journey on a regulated lender's behalf). It describes how we intend to build one: orchestrator-first, with AI architected from Day 1 across the BRE (business rules engine), KYC, document understanding, and contactability. It also covers co-lending, the Indian partner-lending model where two regulated lenders fund one loan at an agreed ratio (the nearest analogues elsewhere are loan participation and forward-flow arrangements), and configurability for every loan type.
Evidence to request from any LOS design.
These are the tests a design should pass, not claims about every current vendor. Hold each one against the operating model, representative cases, and evidence your lender requires.
The LOS has to model an LSP and each of its lender partners.
Ask how partner taxonomy, system-boundary handoffs, and exposure checks are represented and evidenced. Do not infer them from a generic multi-tenant claim.
Lender teams, not the vendor, own configuration changes.
Request a live demonstration of rule, workflow, product, and approval changes, including maker-checker, rollback, and audit evidence.
AI assists inside a boundary. Policy checks stay deterministic.
Require an action boundary, low-confidence path, prohibited-action tests, and evidence that policy checks remain authoritative.
Allocation, rejection, and exposure paths have to be reconstructable.
Test lender-specific rules, quotas, exposure checks, rejection handling, reconciliation, and the evidence retained for every routing decision.
Four areas to evaluate before build.
These roadmap concepts would remain bounded by deterministic policy, verified data, named human authority, exception handling, and reconstructable audit evidence.
A BRE the credit team would author
The proposed design would let credit teams author governed policy, KYC, dedupe, mandate, and pricing rules with versioning, rollback, and change evidence.
- Proposed multi-rule evaluation for allocation, routing, and exposure checks
- Proposed version history and visual change comparison
- Required maker-checker and audit evidence for every change
KYC + identity, agent-native
The roadmap would evaluate consented identity and document workflows with bounded extraction assistance. No named identity-provider integration is claimed today.
- Proposed multilingual extraction with a human-verification path
- Proposed document-quality and tampering checks
- Provider-specific identity flows only after contract and acceptance evidence
Document understanding, application to sanction
The roadmap would combine consented financial-data retrieval, bounded extraction, and reconciliation across income evidence, subject to provider and lender acceptance.
- Proposed provider fallback and explicit failure handling
- Proposed bank-statement normalisation with verification
- Proposed cross-document consistency checks
Contactability before FI/TVR spend
The roadmap would evaluate permitted reachability signals only with a documented lawful basis, source contract, decision boundary, and lender-approved use.
- No silent or provider-specific check is claimed today
- Any cost outcome would require measured pilot evidence
- Missing-signal and retry behaviour would fail into review
Treat co-lending as an attributable system.
The roadmap would require lender-specific policy, rejection handling, exposure checks, reconciliation, and evidence. Exact rules and partner contracts would be implementation decisions.
Lender-specific BRE rules
The proposed design would separate each lender partner's product, eligibility, pricing, fee, and KYC policies without requiring a forked product instance.
Allocation and switching by policy, as designed
The proposed design would route by approved allocation policy and handle rejection through an agreed fallback path. No universal switching limit is published.
Exposure cross-checks
The proposed design would check the exposure inputs and partner limits the lender defines, retain the source evidence, and route unresolved cases for review.
Per-partner workflows
The proposed design would invoke the accepted lender-specific workflow at routing time while keeping versions and decisions attributable.
One composable model, with every product accepted separately.
The roadmap would test whether a shared model can preserve the distinct product, borrower, workflow, asset, policy, accounting, and exception requirements a lender approves.
A product master the lender would configure
The proposed product model would compose a loan type from accepted asset, tenure, interest, charge, repayment, and allocation configuration.
Per-product workflows
The proposed workflow model would bind each product to its approved documents, inputs, approval matrix, and pricing rules.
Asset & collateral handling
The roadmap would model valuation, custody, security creation, and legal evidence per asset class. Named data-provider integrations would require separate verification.
Borrower segments in the product model
The proposed model would let each approved borrower segment carry its own document, business-proof, and underwriting requirements.
Income verification, multi-modal
The roadmap would support lender-approved income sources, bounded extraction, and reconciliation when evidence disagrees. No named bureau or data-provider connector is claimed today.
Lifecycle features per product
Future lifecycle and accounting treatment would be configured only after the lender confirms product scope, applicable policy, and acceptance evidence.
Lender-owned, versioned, and governed.
If delivered as designed, authorised lender teams would control approved rules, master data, workflows, approvals, deviation limits, and communications under maker-checker.
Drag-drop BRE rule builder, on the roadmap
The proposed design would let authorised credit teams compose governed rules visually, with maker-checker, version history, comparison, and rollback evidence.
Master config UIs
The proposed design would expose governed demographic, product, and scheme configuration to authorised lender teams.
Workflow drag-drop
The proposed design would allow reviewed journey, field, and branching changes while preserving rule dependencies and version evidence.
Approval & deviation matrix
The proposed design would give named lender administrators control of approved matrices, limits, escalations, and delegations, with separation of duties.
Pricing boundary between LSP and lender
The proposed boundary would separate pre-routing price proposals from the lender's authoritative pricing and approval controls. Exact ownership would be agreed before implementation.
Intimation templates
The proposed design would version approved communication templates and prevent assisted drafting from changing locked legal text.
Evidence required before availability.
These are design requirements, not a present compliance or certification claim. Product, privacy, legal, security, and risk owners would need to review the applicable evidence.
Failure modes specified before build
The future LOS would require a reviewed failure-mode catalogue, owner, fail-closed behaviour, retry policy, and acceptance test for each material path.
Append-only audit evidence
The future LOS would need reconstructable evidence for data access, rule versions, proposals, approvals, actions, results, and overrides.
Rule-version reconciliation
The future LOS would need controls that reconcile the approved rule and workflow version to each decision and surface mismatches for review.
Data lifecycle controls
Retention, deletion, masking, access, location, consent, and rights handling would be configured to the lender's approved legal and policy interpretation.
Security assurance plan
Required assurance, testing, independent review, remediation, and operating evidence would be agreed before any availability or certification claim.
Current evidence to request; Lokta's roadmap priority.
This is not a named-vendor comparison. The left column states evidence a buyer should request from any current LOS; the right states a proposed Lokta design priority.
| Dimension | Current LOS evidence to request | Lokta roadmap design |
|---|---|---|
| System boundary | Request a published boundary, ownership model, handoff contract, and reconciliation evidence. | Proposed: origination through sanction and mandate, followed by an accepted handoff to the lender's LMS. |
| Implementation plan | Request signed scope, dependencies, owners, acceptance gates, and a duration supported by the named implementation. | No LOS delivery duration is published. Any future plan would require signed scope and evidence. |
| Co-lending workflow | Verify allocation, rejection, exposure, reconciliation, and audit behaviour against representative cases. | Proposed: policy-bound allocation and rejection handling with attributable evidence. |
| AI capabilities | Verify permitted actions, deterministic checks, human authority, accuracy, failure paths, and audit reconstruction. | Proposed: bounded assistance for documents and workflow preparation, with authoritative deterministic controls. |
| Configuration ownership | Verify who may change rules, products, workflows, approvals, and communications, and how changes are governed. | Proposed: lender-owned configuration under maker-checker, versioning, and rollback controls. |
| Product breadth | Verify each required product and asset path with data, workflow, accounting, and exception evidence. | Proposed: a composable product model, with each product accepted separately. |
| Commercial evidence | Request a named scope covering licence, implementation, integration, operation, support, and change costs. | No LOS price or release cadence is published while the product remains on the roadmap. |
Current LOS evidence to request
- System boundary
- Request a published boundary, ownership model, handoff contract, and reconciliation evidence.
- Implementation plan
- Request signed scope, dependencies, owners, acceptance gates, and a duration supported by the named implementation.
- Co-lending workflow
- Verify allocation, rejection, exposure, reconciliation, and audit behaviour against representative cases.
- AI capabilities
- Verify permitted actions, deterministic checks, human authority, accuracy, failure paths, and audit reconstruction.
- Configuration ownership
- Verify who may change rules, products, workflows, approvals, and communications, and how changes are governed.
- Product breadth
- Verify each required product and asset path with data, workflow, accounting, and exception evidence.
- Commercial evidence
- Request a named scope covering licence, implementation, integration, operation, support, and change costs.
Lokta roadmap design
- System boundary
- Proposed: origination through sanction and mandate, followed by an accepted handoff to the lender's LMS.
- Implementation plan
- No LOS delivery duration is published. Any future plan would require signed scope and evidence.
- Co-lending workflow
- Proposed: policy-bound allocation and rejection handling with attributable evidence.
- AI capabilities
- Proposed: bounded assistance for documents and workflow preparation, with authoritative deterministic controls.
- Configuration ownership
- Proposed: lender-owned configuration under maker-checker, versioning, and rollback controls.
- Product breadth
- Proposed: a composable product model, with each product accepted separately.
- Commercial evidence
- No LOS price or release cadence is published while the product remains on the roadmap.
Compare only like-for-like scope and verified evidence. Lokta Loan Origination is not available now; the roadmap priorities above are not delivery, price, or outcome commitments.
Three groups that can test the design assumptions.
Evaluate the multi-lender operating model.
Help test the proposed partner taxonomy, lender-specific policy, handoff, exposure, and reconciliation boundaries before they become delivery commitments.
Evaluate a transition to partner lending.
Use the proposed design to identify which operating, policy, data, and control boundaries would need to change before an implementation can be scoped.
Evaluate the proposed product model.
Bring representative products and exception paths to test whether one composable model can preserve their distinct documents, decisions, approvals, assets, and accounting needs.
Origination is one layer of the stack.
Questions buyers ask first.
Roadmap position, differentiation, integrations, AI position, and configuration ownership.
Where does origination sit on the Lokta roadmap?
Loan Origination is on the roadmap and is not available now. No release date is published. Today Lokta offers Loan Management and AI Loan Servicing, which run the book after approval; lenders keep their existing LOS and board the approved loan into Lokta at disbursement. This page publishes the proposed LOS design so lenders can assess the direction and discuss priorities with us.
How is this different from off-the-shelf LOS?
The proposed design has three priorities: an explicit LSP-to-lender handoff at disbursement, AI-assisted document and workflow operations behind deterministic checks, and business-owned configuration with governed approvals. These are roadmap design goals, not available features or a current integration commitment.
How does co-lending actually work?
Co-lending pairs two regulated lenders on one loan at an agreed funding ratio, each carrying its share of the exposure. The roadmap design would let a lender define partner-allocation rules, quotas, exposure checks, rejection handling, and controlled switching. Exact switching limits, partner contracts, checks, and acceptance criteria would be implementation decisions. None of this is available in Lokta Loan Origination today.
What integrations ship out of the box?
No out-of-box integration is claimed for the roadmap LOS. The proposed architecture anticipates adapters for identity and KYC, bureaus, bank-statement data, signatures, mandates, reachability, asset records, and document systems. A named provider should be treated as available only after its connector, contract, data flow, and acceptance evidence are verified.
What's the AI position, really?
The proposed design would use AI to assist document handling, data extraction, workflow preparation, and contactability signals. Deterministic eligibility, policy, exposure, and approval checks would remain authoritative, with low-confidence and exception cases routed for review. This describes the roadmap boundary, not a shipped LOS capability.
Who owns configuration after go-live?
If delivered as designed, lender product, credit, and operations teams would own approved rule, product, workflow, approval-matrix, and communication configuration. Maker-checker and version evidence would govern changes. The operating model would need to be agreed and accepted before any future deployment.