Talk to us
Glossary · Lokta concept vocabulary

Lending ontology

A lending ontology is one canonical model of the loan (borrower, application, repayment, and risk, plus the relationships between them) that the whole lending stack reads and writes through, instead of a separate copy of the loan in every system.

  1. Proposed loan change
  2. One loan object
  3. Views derive from the record
Illustrative example

A borrower asks to move the EMI date. In a five-copy stack the request is a ticket in the CRM, a schedule edit in the LMS, a mandate amendment in the payments system and a manual note for collections. On one ontology it is a single proposed change to the loan object. The schedule, the mandate, the accrual and the collections view all derive from it, and the audit log shows one event with one approver.

Where most stacks keep the loan as five drifting copies (LOS, LMS, core/GL, collections, warehouse) that have to be reconciled, a lending ontology resolves them into a single canonical loan object on a deterministic core. Governed AI and people act on the same truth, every change is logged on one append-only trail, and the book can sharpen itself the more it lends, because every outcome writes back to the same model. Lokta applies this operating layer to the post-approval live book today and accepts the handoff from a lender's existing origination system. Loan Origination is on the roadmap and is not available now. No release date is published. The model itself is laid out on the lending ontology page.

The ontology matters after approval because that is where the loan changes most. Every repayment, bounce, waiver, part-prepayment, bucket move and settlement is a write, and each write has to land on the same object that the collections queue, the accounting close and the borrower statement are reading. When the model is shared, an agent's proposal, a person's approval and the ledger posting are three steps on one record rather than three records to reconcile.

See the lending ontology →

How is a lending ontology different from a data warehouse?

A warehouse copies data out of the operating systems after the fact, for reporting. An ontology is the model the operating systems write to in the first place. A warehouse can say what the book looked like last night; an ontology is what the book is right now, which is the only version an agent can safely act on. A lender may well need both, but a warehouse cannot stand in for the shared model, because it inherits every inconsistency the source systems had.

Which entities does a lending ontology have to cover?

At minimum the borrower, the loan account and its schedule, every transaction against it, the security where there is any, the policy version in force, and the actors who acted: staff, partners, workflows and agents. The relationships matter as much as the entities. A repayment belongs to a loan, which belongs to a borrower, was allocated under a policy, and was posted by someone, and each of those links is what makes a later question answerable.

Does an ontology mean one vendor for the whole stack?

No. It means one canonical model that every system reads and writes through, and that can sit behind APIs other vendors integrate with. What it rules out is each system keeping its own private copy of the loan as the truth. That is a design rule for the integrations, not a procurement rule for the vendors.

Related terms

  • Agent-native lending (Agent-native lending platform)An agent-native lending platform is a lending core built to be operated by agents (software that reads the loan, decides, and acts) rather than by people clicking through screens.
  • Deterministic coreA deterministic core is the layer of a lending platform whose outputs are fully reproducible from inputs and policy: no probabilistic models, no LLM calls, no hidden randomness..
  • Workflow AI vs agentic AIWorkflow AI assists a human inside an existing process; agentic AI runs the multistep process end-to-end.
  • Audit-by-designAudit-by-design is the principle that every decision a lending platform makes (human, workflow AI, or agent) produces a tamper-evident record that a regulator or internal auditor can replay..

All terms in the Lokta lending glossary →

Founder-led adoption

Adopt the agentic loan servicing platform.

Lokta is built for enterprise deployment, VPC or single-tenant cloud, with an audit trail in every state change. We work with a select group of institutions through a founder-led model: deep adoption, deliberate scope, a delivery window the team commits to in writing.

Talk to us
contact@lokta.ai+91 77958 37582