You can't run
agents on narrow
gauge LMS rails.

Agentic workflows don't just "use data." They execute with governance and generate 5–10× more tool calls. Legacy LMS becomes the bottleneck.

CATEGORY
Loan Management System · AI-Ready Infrastructure
FOR
Lenders · NBFCs · Fintechs
FIG. 01 · GAUGE COMPARISON ● LIVE
NARROW · LEGACY LMS · 8–15 calls WIDE · LOKTA · 60–120 calls PER ACCOUNT 8–15 60–120 5–10× MULTIPLIER
COLLECTIONS

5–10× the execution load.
Same workflow.

Manual load is linear. Agentic load isn't. Here's the math.

HUMAN-DRIVEN

Manual load stays linear.

An agent skims DPD, dues, last payment, notes — then decides. Most context-stitching happens off-platform.

01Open account
02Check dues + last payment
03Skim notes + PTP
04Decide next action
05Add note, move on
8–15
CALLS / ACCOUNT
~80k
CALLS / DAY @ 10K
Point-in-time, asynchronous interactions
AGENTIC · GOVERNED

Agentic load is non-linear.

An agent must fetch + verify the full Collections 360 before acting, then log evidence and emit events.

01Query & fetch full Collections 360
02Validate policy + consent
03Orchestrate multi-channel comms
04Log evidence, reasoning, result
05Emit events, verify write-back
60–120
CALLS / ACCOUNT
1.2M
CALLS / DAY @ 10K
CRITICAL Data-readiness bottleneck — continuous, synchronous execution

on Lokta rails, the platform stops being the bottleneck.

WHY NOW

The bullet train problem.

Illustration: a high-speed bullet train approaches a broken section of narrow-gauge track over a chasm — the rails for the next decade of lending aren't there yet.

Bullet train ≠ faster engine.

Agentic workflows are the bullet train. Legacy LMS is narrow gauge. Patchable, not future-proof.

"AI-ready isn't a feature you can bolt on later — it's a systems property."
Read more →
WHY LOKTA

Built for both
sides of the market.

Two winners next decade: lenders who automate safely, and builders who ship agents fast.

FOR LENDERS

Compliance-grade execution.

  • A1Audit trails on every action
  • A2Deterministic truth across systems
  • A3Scale automation safely
  • A4Full control of the loan book
  • A5Joint liability is a citizen of the platform, not a retrofit

FOR FINTECHS

Build lending agents fast.

  • B1Clean primitives
  • B2Agent-ready tools
  • B3Governed write-backs
  • B4Faster time-to-market
  • B5The borrower surface ships with the platform — your agent is the face on top, not the foundation underneath
WHAT AI-READY MEANS

AI-ready isn't a feature.
It's infrastructure.

FIG. 01

Nothing is anonymous

Every action, by a human or an agent, has a name attached. The kind of legibility a CRO can sleep on.

FIG. 02

Events

Complete event catalogue with versioning, idempotency, replayable history.

FIG. 03

Data Pipelines

Every change streams into analytics-ready storage with feature views.

FIG. 04

Trust by structure

Trust is not a feature you opted into — it is the shape of the platform. Sensitive data does not arrive in the wrong place because the structure refuses to carry it there.

FIG. 05

Orchestration

Native case flows with tasks, approvals, escalations, rework loops.

FIG. 06

Observability

Trace what happened, why, and who approved it across every layer.

WHY LEGACY BREAKS

AI-ready is a systems property,
not a feature you can bolt on later.

When agentic execution enters collections, every missing event, weak boundary, and disconnected workflow shows up as operational drag or compliance risk.

F01 Operational schema is not feature history
F02 Partial events with no replay strategy
F03 No canonical Collections 360
F04 Outcomes trapped inside notes
F05 Workflow logic lives outside core systems
F06 Weak decision trails, missing why
F07 Limited policy boundaries for AI
F08 Security posture built for humans only
THE FINE PRINT

Lending lives in the fine print.
So do we.

Loan books are won and lost in the small decisions a regulator never asks about — until they do. The four below are not features. They are the kind of choices we made before anyone asked.

P01 foreclosure settlement breakdown surfaces on the transactions API
P02 the loan-participant closure validator rejects closure when a primary participant has non-terminal loans elsewhere
P03 the customer loans tab shows the canonical account number, not the external ID
P04 pre-EMI interest emits a standalone billing-point row plus the twelve EMIs

Every change above passed the same gate that guards the rest of the platform.

WHAT SHIPS TODAY

What you get
on day one.

The capabilities a lender can rely on the platform to provide today.

  • Architecture

    • Polylithic Gradle modules
    • Single Spring Boot deployable
    • OpenAPI 3.1
    • Header-based API versioning (api-version: 1|2)
    • Liquibase change management
    • jOOQ + JPA dual access
  • Multi-tenancy

    • Schema-per-tenant isolation
    • Shared Keycloak realm mode
    • Dedicated Keycloak realm mode
    • Per-tenant numbering & code values
  • Identity & governance

    • Keycloak IAM
    • RBAC
    • Permission groups
    • OrgUnit hierarchy
    • Maker-checker workflow
    • Cross-module audit trail
    • Field-level PII encryption with key versioning
  • Loan product assembly

    • Multi-currency (ISO 4217)
    • Repayment frequency (RRULE)
    • Interest method — FLAT, DECLINING, FLAT_TO_DECLINING
    • Charges engine
    • Arrears configuration
    • Precision rules
    • Repayment allocation strategy
  • Loan lifecycle

    • SUBMITTED → APPROVED → ACTIVE → CLOSED / WRITTEN_OFF
    • Disbursement (full + partial)
    • EMI schedule generation
    • Restructuring & moratorium
    • Write-off (FULL, PRUDENTIAL)
    • Asset classification — STANDARD / SUB_STANDARD / DOUBTFUL / LOSS, configurable DPD

UNDER NDA Integrations and AI / agent surface delivered with deployment, sequenced to your priorities. Detailed timeline and partner ecosystem available under NDA.

LOKTA vs FINERACT

If you have evaluated Fineract,
here is the honest read.

We helped build Apache Fineract. We respect what it is.
Here is where the architectures diverge for the agentic era.

CONCESSION

Fineract leads on community size, breadth of installed base, regulator familiarity in 30+ countries, accounting depth, and savings / microfinance feature surface.

Dimension Apache Fineract Lokta Core
Change velocity Modular monolith — module boundaries are soft, changes can ripple. Strict module boundaries — teams ship one piece at a time without touching the rest.
Tenant isolation Database-level separation between tenants. Database isolation + dedicated identity space per tenant for regulated lenders.
User access & SSO Built-in role-based access controls. Enterprise identity with single sign-on, fine-grained permissions, and org hierarchy out of the box.
Integration stability REST APIs with auto-generated docs. Versioned API surface — older integrations keep working when newer ones ship.
Approval controls Per-action maker-checker toggles. Workflow-grade approvals with full change-request lifecycle and audit trail.
Audit trail for regulators Per-table audit. Cross-module structured audit on every state change — actor, evidence, before / after.
Compliance & PII protection Field-level encryption. Field-level encryption with key rotation — meets evolving compliance posture.
New-product launch speed Template-based product configuration. Compose products from primitives — currency, frequency, interest, charges, arrears — ship in days.
NPA classification flexibility DPD-based classification. Configurable DPD thresholds + explicit asset lifecycle (Standard → Sub-Standard → Doubtful → Loss).
AI & agent readiness Built before the agentic era — not designed for it. Canonical data model, governed APIs, identity for agents — built for agentic operations.
Real-time vs batch Polling and batch processing. Event-driven — real-time state with replayable history.

Read the full essay → Fineract's cumulative lending impact →

LOKTA vs TRADITIONAL LMS

Versus the traditional
core LMS category.

Mature platforms built for the human-driven era.
We aren't naming vendors — this is positioning, not procurement.

Dimension Traditional core LMS Lokta Core
Deployment Vendor-managed SaaS On-prem · single-tenant cloud · VPC (you choose)
Tenancy Single-tenant per institution Multi-tenant by schema, dual IAM modes
Customisation Configurable, vendor-gated extensions Open module surface — your engineers extend in-tree
Time-to-launch a new product Weeks (vendor change request) Days (config-driven assembly)
Data residency Vendor-region constrained Pick yours
Audit posture Per-product reports Cross-module structured audit
AI-readiness Bolt-on integrations to vendor APIs Foundations native — canonical model, governed APIs, identity for agents
Vendor lock-in High Lower — you operate the binary
Product direction Vendor-led Co-design partnership available
FOUNDATIONS → AGENTIC VISION

The foundations
make the surface safe.

Canonical model, governed APIs, identity for agents, audit trails — these are in the platform now, so that agents are something you enable on Lokta, not bolt onto a system that wasn't designed for them.

FOUNDATIONS · SHIPPED

What is in the platform today.

  1. F01

    Canonical loan / customer model

    Stable IDs across modules — the same customer, the same loan, everywhere.

  2. F02

    Governed API surface

    Header-versioned, OpenAPI 3.1, audit on every mutation.

  3. F03

    Identity for agents

    Keycloak realms support service principals. RBAC + permission groups scope what an agent can do. Maker-checker forces approval on policy boundaries.

  4. F04

    Audit trail

    Every mutation captured with actor, evidence, before / after. Cross-module structured.

  5. F05

    PII protection

    Field-level encryption with key versioning, so agent prompts can be safely scoped.

AGENTIC SURFACE · DELIVERED WITH DEPLOYMENT

What runs on top of the rails.

  1. V01

    Servicing operations copilot

    Drafts charge waivers, mandate updates, schedule corrections, and statement adjustments — grounded in canonical loan state. Maker-checker enforced on every mutation; full audit trail by default.

  2. V02

    Collections agent

    Fetches Collections 360, validates consent + policy, orchestrates outreach, logs evidence, emits events. The collections picture above, made explicit as a deliverable product.

  3. V03

    Borrower agent

    Handles statement, foreclosure quote, part-payment, NACH re-mandate. Grounded in canonical loan state. Escalates on hardship signals.

  4. V04

    Portfolio agent

    Continuously watches DPD trajectories, flags candidates for restructuring, drafts asset-reclassification proposals, routes to maker-checker.

PRINCIPLE Every agent on the right is an application of the foundations on the left. The rails make the surface safe — and the surface deploys as part of the engagement, sequenced to your priorities.

WHAT THIS ENABLES

Built to move four numbers
your CFO already tracks.

These are the targets the architecture is built to enable.
Not observed averages — committed pilot ranges will be in your RFP response.

  • COST-TO-SERVE IN COLLECTIONS

    Automation feasibility on safe rails — the collections agent (V02) sized for the 5–10× tool-call workload your CFO will see in the OPEX line.

    TARGET · ENABLED BY ARCHITECTURE
  • Days TO LAUNCH A NEW LOAN PRODUCT

    Config-driven assembly: currency × frequency × interest method × charges × arrears × precision × allocation. Not a vendor change request.

    TARGET · ENABLED BY ARCHITECTURE
  • T+1 NPA DETECTION

    DPD thresholds + asset classification run on current state, not yesterday's batch. Provisioning math moves with the book, not behind it.

    TARGET · ENABLED BY ARCHITECTURE
  • All STATE TRANSITIONS AUDITED

    Every mutation captured with actor + evidence by design. Audit posture is structural — not a separate pipeline that can fall out of sync.

    TARGET · ENABLED BY ARCHITECTURE

CAVEAT These targets describe what the platform is engineered to enable. Specific commitments are negotiated per engagement and depend on baseline state, integration scope, and policy configuration.

FAQ

Questions buyers ask first.

Rollout, deployment, residency, integrations, and the AI surface.

  • How long does a Lokta Core rollout take?

    Co-design partner deployments target 8–12 weeks for the first product live. Actual timeline depends on integration scope, data migration, and policy configuration.

  • Where can Lokta Core run?

    On-prem, single-tenant cloud, or VPC. You choose the data residency. Same binary either way — we ship modules, you operate one Spring Boot deployable.

  • How do you handle data residency for cross-border lenders?

    Schema-per-tenant isolation plus per-tenant deployment topology. Tenants pin to specific regions, and tenant boundaries are enforced at the schema level, not just the application layer.

  • How customisable is the loan product engine?

    Compositional: currency × frequency × interest method × charges × arrears × precision × allocation. Most loan products assemble from configuration, not code. New product variants typically ship in days, not weeks.

  • What integrations are available?

    A governed OpenAPI 3.1 surface with header versioning is in the platform today. KYC, credit bureau, payment gateway, core-banking bridge, accounting connectors, and SMS / email are delivered with deployment — sequenced to your priorities, with a delivery window the founder commits to in the RFP response.

  • What is your AI position?

    The platform is built so that agents — servicing operations, collections, borrower, portfolio — run safely on top of canonical state, governed APIs, identity for agents, and audit trails. The agent surface is delivered with deployment, sequenced to your priorities. Detailed timeline and partner ecosystem available under NDA.

  • How is Lokta different from Apache Fineract?

    Same heritage, different generation. We helped build Fineract; Lokta Core is the rebuild for the agentic era. The architectural diff lives in the Lokta vs Fineract comparison above.

CLOSING

Ready to evaluate
Lokta Core?

Two ways to start. Both are direct to the founder.

RFP Package

WEB · ~24 pp · PRINT-READY

Capabilities matrix, security posture, deployment options, integration approach, architecture, and a response template your procurement team can fill in. Open in browser, Cmd-P to PDF.

Talk to a founder

REPLY WITHIN 24H

If you would rather skip the package and go straight to a conversation about your stack, your timeline, and what a co-design partnership looks like — we will reply within a business day.

Talk to the team

Adopt the next-decade lending stack with Lokta

Lokta Core is enterprise-ready and deploys under engagement. 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.