Your vendor questions, answered before the first call

Yes. A product is a versioned configuration built from 200 parameters in Loan Product Studio, grouped into nine areas from interest engine and schedule to charges, repayment and accounting. An authorised user builds it, tests it and submits it for approval, with no code release. Contradictory settings are flagged before the product reaches a borrower.

Source: Loan Management

Each tenant holds its own configuration, numbering and code values. Inside a tenant, a segment or portfolio that needs different terms becomes its own product or variant, and partner commissions are set through partner agreement and fee rules. A lending service provider can version policy separately for each lender it services.

Answered in the proposal: whether one product can carry rule overrides by geography, and how such an override is approved.

Source: The lending ontology

Yes. Each product takes an ISO 4217 currency with its own rounding rules. Repayment frequency is a recurrence rule, daily, weekly, monthly or yearly, and daily interest accrual with effective-dated floating rates is supported.

Charges are defined at product level as a flat amount or a percentage, with their own timing, grace, caps, tax and waiver rules. A penal charge stays separate from contractual interest and is never capitalised. The appropriation order is set per product, and a waiver keeps the original charge and the approving action on the account.

Source: Payment appropriation

Yes. Maker-checker governs product approval, and the reviewers follow what the product configures: finance signs the GL mapping, risk the classification, compliance the KFS and penal charges. A product does not move to pilot until each of them has signed, and every sign-off lands on the audit trail.

Source: Loan Management

Yes. New terms apply to new loans from the approved effective date, and a loan already booked keeps the version it was booked under. A change to an existing loan goes through an authorised servicing action with a revised schedule, never a silent rewrite of booked terms.

SUBMITTED, APPROVED, ACTIVE, CLOSED and WRITTEN_OFF, with restructuring, moratorium, write-off and asset classification as first-class events on top. Lokta takes the loan from approval onward. Loan Origination is on the roadmap, so the approved loan arrives from the lender’s own LOS by API.

Source: Loan Management

Yes. Tranches are recorded against the sanctioned limits, and the obligation is recalculated for the amounts and dates actually disbursed. Payouts can be initiated from Lokta through a Cashfree integration, and a failed or pending payout waits in an exceptions queue with its reason code.

Yes. Schedules can be equated, step-up, step-down, bullet or set instalment by instalment. A moratorium can relieve principal, interest payment or interest accrual, and its effect on later dues is shown before rollout.

Yes. Restructuring and rescheduling regenerate the schedule and keep the change history and classification treatment. A refinance settles the old obligation and books the replacement, with both records kept. Write-off is full or partial behind an approval workflow, and later recoveries post separately against the written-off account.

RBI IRAC and SMA classification runs automatically on the ledger, with the DPD thresholds held in configuration. On NPA classification, accrual stops or moves to memorandum as the lender’s policy sets, and income is recognised on receipt. Because the ledger replays, any classification can be re-derived from the loan’s history.

Source: SMA and NPA classification

Yes. A backdated correction regenerates the schedule deterministically and books its accounting effect as new double-entry postings. Corrections reverse entries that reference the original, so the original stays in the record.

Source: Loan Management

Yes. DPD and the overdue view are computed from the same record as the loan, and bucket movement follows from them. Staff can pull a loan’s DPD or a bucket queue directly, including read-only through the Lokta MCP server.

Source: Lokta MCP server

Bucket definitions and DPD bands are configurable, and overdue views filter by product today.

Answered in the proposal: how bucket rules differ by partner when one product is sourced through more than one partner.

Queues and assignments work at the user-login level today, segmented by DPD and product. Automatic segmentation on balance, risk and other business rules belongs to the expanded collections release, which is on the roadmap.

Yes. A promise to pay is recorded on the account, followed up, and its outcome carried back to the live loan. Interaction history sits on the same record, and auto-debit can be suppressed while a promise stands.

Source: AI Loan Servicing

Yes. Settlements sit behind the maker-checker change-request lifecycle with waivers, reschedules and write-offs. The servicing agent can propose a settlement, and it cannot approve or post one.

Not today. No-code strategies and escalation rules, which is where a priority rule like this lives, are part of the expanded collections release on the roadmap, with no date published.

Yes. Disbursement, accrual, a fee, a repayment, a waiver, a write-off or a reversal each create balanced debit and credit postings to the configured GL accounts. The loan ledger and the accounting ledger sit on one event-sourced record, so the two never need matching at month end.

Source: Loan Management

Yes. GL mapping is part of each product’s configuration, covering portfolio, interest and fee income, penalty income, receivables, suspense and write-off accounts. Charges carry their own tax treatment, and cost centres or branches are available as GL dimensions. Authorised finance users change the chart of accounts without code, under maker-checker.

An authorised user reverses an eligible posting inside the accounting-period and approval controls. The reversal references the original transaction, and both stay in the history with who made them.

A failed mandate debit is recorded as a payment exception, never as cash received, so the instalment stays due and feeds DPD. Bounce charges are their own charge definition with grace, caps and waiver rules. A failed payout to a borrower waits in an exceptions queue with its reason code.

Yes. Provider payout and collection files and bank statements are matched against ledger entries, and breaks surface with proposed matches for finance to accept or reject. A bank statement can be uploaded and posted to loans, each loan tagged to its lender where more than one lender is involved. Funds that cannot be matched yet sit in suspense with an ageing view.

Yes. Identity runs on Keycloak with OIDC and OAuth2, including service principals for backend integrations. A tenant sits in a shared or a dedicated realm, depending on its risk profile.

Yes. Access is role-based with permission groups. The same roles bound the servicing agent and the MCP connector, so an assistant sees only what the signed-in person’s role allows.

Source: Lokta MCP server

Yes. An OrgUnit hierarchy with tree operations is part of identity and governance, and authorisation follows it.

Yes. The cross-module audit trail records every mutation with actor, action, evidence and the state before and after. Events and their journal entries are append-only.

Source: Audit trail in an LMS

Yes. Sensitive fields are encrypted one by one with versioned keys, and a key can rotate without re-encrypting historical ciphertext. Decrypting a field is checked against the caller’s authorisation.

Yes. Tenant scope, OrgUnit and role decide what a user or an agent can read or propose, and a sensitive field decrypts only inside an authorised context. Through the MCP connector, borrower details arrive masked unless the lender turns masking off.

Answered in the proposal: whether an on-premises deployment fits your requirements. The published options are in-region hosting on AWS and, on Enterprise, Docker images deployed into a VPC in your own cloud account.

Yes, on the Enterprise tier. Lokta arrives as Docker images inside the lender’s own VPC, on AWS or another cloud, and the lender’s own services can run beside it and call its APIs over the private network.

Source: Pricing

Yes. Lokta is hosted in-region on AWS, and each lender gets its own deployment rather than a slot in a shared one.

Source: Lokta Next 100

Each tenant has its own deployment topology and is pinned to a region. Borrower data stays in-region, and a lender working across borders runs a separate deployment for each residency boundary.

Both. Each tenant has its own Postgres schema, and tenant context is enforced at the database connection as well as in the application.

Yes. The OpenAPI 3.1 specification is generated from the controllers and covers 314 published REST endpoints. The current API reference is linked from the integrations page.

Source: Integrations

URL-based. The version sits in the path (/v1, /v2), and an older version keeps serving beside a newer one, so an integration does not break when the next version ships.

Lokta is the system of record for the loan book: an existing book migrates onto its Loan Ledger and Accounting Ledger. It covers the lending side of a core (loan sub-ledger, accruals, general ledger, day-end and month-end), and carries no current or savings accounts. A core banking system or escrow account connects around that record, mapped and reconciled to the lender’s contract.

Source: Integrations

Yes. Ready today: Cashfree for payouts and payments, Digio for KYC, Gupshup for SMS and WhatsApp, SMTP email, and credit-bureau reporting. Bureau pulls and Account Aggregator are added once the lender selects its providers.

Answered in the proposal: the delivery plan for any provider outside this list.

Source: Credit bureau reporting

Tally posting is ready: reviewed journal entries sync on a schedule, mapped to Tally ledgers, groups and voucher types, and unmapped postings are held for resolution. The trial balance and journals also export to the lender’s finance system. Any other accounting system is scoped and tested as its own integration.

Yes. The servicing agent reads the borrower message with the loan behind it: schedule, mandate status, overdue history, charges and lifecycle state. It answers from that record and approved knowledge, never from the message alone.

Source: AI Loan Servicing

Yes. It explains the overdue amount, charges, how a payment was appropriated, schedule changes and bucket movement. Every figure comes from the deterministic core, and the model passes it on unchanged.

Source: Lokta MCP server

Yes. Account summaries and exception explanations are part of what the agent prepares for the servicing team. Staff can also ask Claude about a loan, read-only, through the Lokta MCP server.

Yes. A suggested waiver, reschedule or foreclosure quote goes through maker-checker, and no state-changing action runs without an authorised approver. The boundary is set workflow by workflow, and nothing is automated until the lender signs it off.

Yes. Prompts, responses, the data accessed and the resulting actions go into the same audit trail as human servicing actions. AI is opt-in, estimated before it switches on, and can be switched off at any time.

Source: Lokta Next 100

The book migrates onto Lokta’s ledgers and is proven in a parallel run: a sample of loans runs on both systems, and the switch happens only when balances reconcile line by line. The current system keeps running until then. The indicative timeline is six weeks to four months, set by product count, integrations, migration depth and how much of the lender’s team is free.

Source: Implementation timeline

Yes. The loan master and terms, the schedule as billed, ledger and GL history, classification history, charges and waivers, and bureau history move together against one freeze date. Balances, DPD and accounting are then proven against the outgoing system before cutover.

Source: The cutover sequence

After go-live, support is by email and phone, with response times set by severity. The commitments are written into the agreement.

Answered in the proposal: the committed uptime, the response time for each severity and the escalation path.

Every Lokta response carries a section on what is not ready today and the dependencies and sequencing risks in your scope, with the mitigation for each. The migration assessment ends in a written plan or a written recommendation to stay.

Source: Migration assessment

Three published tiers. Starter is Lokta Next 100 for lenders with assets up to about USD 10 million, or the local equivalent (₹100 crore in India): no platform fee for 24 months, with one-time migration (₹1 lakh) and bank-integration (₹50,000) fees in India. Scale-up is ₹1,000 per crore of assets, per month (USD 100 per USD 1 million of assets, per month), which is 1 basis point, plus implementation of USD 5,000 to 10,000. Enterprise is priced in the proposal.

Answered in the proposal: payment milestones and renewal terms for your tier.

Source: Pricing

Yes. Acceptance and rollback criteria are written before any trial starts, and cutover follows one freeze date in a fixed order. The morning after, ledger balance, accounts by bucket and charges outstanding are checked against the snapshot before a new payment posts.

Source: The cutover sequence

In the lender’s region, on AWS; in India for lenders in India. On the Enterprise tier, the deployment sits in the lender’s own cloud account, in the region the lender chooses.

Answered in the proposal: the named AWS regions for primary data, backups and disaster recovery.

Each tenant is pinned to a region through its own deployment topology, and a lender working across borders runs one deployment per residency boundary.

Answered in the proposal: written confirmation that no replication leaves the contracted region.

On the Enterprise VPC deployment, Lokta runs as Docker images inside the lender’s own VPC, so what it writes stays in that account. The MCP connector’s request log is written to the lender’s own Lokta database.

Answered in the proposal: where each log, backup and analytics copy lives on the hosted deployment.

Yes. One deployment per residency boundary is the stated pattern, and the Enterprise tier covers more than one entity.

AI is opt-in, so no model-inference path runs until the lender approves it. Once it is on, the model the lender approves drafts proposals, and the governance above it does not change with the model.

Answered in the proposal: the support and monitoring access paths, and the region of any model provider you approve.

By deployment topology. The region is fixed by where the deployment runs, and on Enterprise that is the lender’s own cloud account, which the lender’s security team can inspect directly.

Yes. TLS terminates at the deployment edge, and mTLS is available for service-to-service traffic where the lender requires it.

Sensitive personal fields are encrypted one by one, above any disk-level encryption.

Answered in the proposal: database and backup encryption at rest on the chosen deployment.

Yes. PII is encrypted at field level with versioned keys.

Keys are versioned and rotate without re-encrypting historical ciphertext.

Answered in the proposal: the key store used and how keys are held apart from the data.

Yes. Key versioning keeps every historical record readable after a rotation, with no bulk re-encryption.

Decrypting a field is checked against the caller’s authorisation.

Answered in the proposal: who holds key access, and how each key-access event is logged.

Yes. Roles carry permission groups, and a person gets access through a role. The MCP connector, for example, needs its own permission added to a role before anyone can use it.

Source: Lokta MCP server

Yes. Authorisation follows the OrgUnit hierarchy inside a tenant, and tenants are separated at the schema. A lending service provider can keep policy versioned per lender.

Identity runs on Keycloak with OIDC and OAuth2.

Answered in the proposal: federation with your named identity provider.

Product changes, waivers, reschedules, write-offs and settlements all pass through the maker-checker change-request lifecycle, and so do chart-of-accounts changes.

Answered in the proposal: the maker-checker configuration for disbursals.

Approval boundaries are set workflow by workflow, so they vary by action type.

Answered in the proposal: approval rules by amount band and risk level.

Answered in the proposal: how privileged and break-glass access is granted, limited in time and logged.

Maker-checker is two people: one proposes, a different authorised user approves.

Answered in the proposal: confirmation that no configuration lets a user approve their own change.

Yes. Every mutation is recorded with actor, action, evidence, timestamp and the state before and after.

Source: Audit trail in an LMS

The trail is append-only: a correction is a new entry that references the original, and nothing is edited or deleted.

Answered in the proposal: the mechanism that makes tampering evident.

Yes. Agent prompts, responses, data accessed and resulting actions use the same structure as human servicing actions, and every MCP connector request is logged too.

Journal entries, loan transactions, sub-ledger balances and the trial balance can be inspected and exported through reports and APIs, and a question such as who changed a schedule can be asked directly.

Answered in the proposal: the export format for the full audit trail.

Retention follows the tenant’s own policy. Sign-in records for the MCP connector are kept for 90 days.

Yes. The ledger replays: given a loan’s history, it re-derives today’s position entry by entry.

Source: Loan Management

KFS and APR disclosure is configured per product and signed off by compliance. A payout is made from the lender’s own payout account to the borrower’s verified bank account.

Answered in the proposal: how the cooling-off period is handled for your products.

Source: Penal charges and rate resets

Yes. Terms, charges and KFS sit on the versioned product, each loan keeps the version it was booked under, and charges and waivers stay visible on the account and statement.

Yes. Hosting is in-region on AWS, and on Enterprise the deployment runs as Docker images inside the lender’s own VPC, in the same region.

Yes. Regulatory extracts, NPA and asset classification and the audit trail come from the same ledger the book runs on. The demo catalogue holds 104 reports across eight domains.

Source: RBI returns for NBFCs

A regulatory change is configured once and every product inherits it. The lender keeps its lending decisions, policies and regulatory interpretation.

Answered in the proposal: the contractual commitment for shipping a regulatory change.

Answered in the proposal: how access, correction and erasure requests are handled.

Collections checks contact hours and consent before a message goes out.

Answered in the proposal: how consent is versioned, and how purpose and withdrawal are recorded.

Source: AI Loan Servicing

Customer, loan and collateral are connected entities in one data model, so a customer’s records hang off one identity.

Answered in the proposal: the procedure for a subject request across records and logs.

For the MCP connector, the lender stays the data controller and Lokta processes data on its instructions.

Answered in the proposal: the data processing terms for the full engagement.

Source: Lokta MCP server

Through the MCP connector, names show only initials and mobile and ID numbers only their last four digits, and a request containing an Aadhaar number is refused.

Answered in the proposal: the masking rules for non-production and analytics copies.

Answered in the proposal: retention settings by data category and obligation.

Answered in the proposal: the deletion or anonymisation method and the evidence it leaves.

Answered in the proposal: how retention and deletion apply to backups and replicas.

The accounting record is append-only, and corrections never delete an original entry.

Answered in the proposal: how a deletion request is reconciled with the records you must keep.

Customer, loan, transaction, journal and configuration data can be exported in open formats at any time. Source code can be placed in escrow with an agent the lender chooses.

Answered in the proposal: exit terms, including any fee on exit.

Answered in the proposal: the committed RTO and RPO, written into the agreement.

Answered in the proposal: backup frequency and the date and result of the last restore test.

Answered in the proposal: the disaster-recovery plan and its last exercise.

Answered in the proposal: the redundancy design inside the contracted region.

Answered in the proposal: the availability commitment and how downtime is measured and reported.

A VAPT is in progress.

Answered in the proposal: the VAPT summary under NDA once it is issued.

Answered in the proposal: the closure record for VAPT findings.

ISO 27001 certification is in progress. No SOC 2 report is claimed.

The engine is tested with combinatorial automated cases across its parameters and paise-exact golden schedules, and schema changes go through Liquibase change management.

Answered in the proposal: code review, dependency scanning and secrets-management practice.

Source: Loan Management

Vulnerabilities go to support@lokta.ai with Security in the subject line, and every report is looked into.

Answered in the proposal: remediation times by severity.

Source: Lokta MCP server

Hosting is on AWS. Payouts through Cashfree and KYC through Digio run on the lender’s own accounts with those providers.

Answered in the proposal: the full named sub-processor list, including any model provider.

Answered in the proposal: the operating region of each sub-processor.

Answered in the proposal: the flow-down terms for sub-processors.

Answered in the proposal: the notice period and objection right for a new sub-processor.

The lender’s data is never used to train models for anyone else.

Answered in the proposal: the same commitment for each sub-processor.

Source: Lokta Next 100

Answered in the proposal: the breach-notification commitment in hours.

Answered in the proposal: the incident-response process document.

Answered in the proposal: who notifies the regulator and data principals, and on what timeline.

Answered in the proposal: how post-incident reviews are shared.

No. The agent proposes and the core posts, after the policy and approval check, and a named person approves every financial and loan-state action the workflow marks for review. The proposal, the approval and the outcome land in the same audit trail as a human action.

Source: AI Loan Servicing

No. The lender’s data is never used to train models for anyone else, and AI itself is opt-in and can be switched off at any time.

Source: Lokta Next 100

It fails safe. A low-confidence case can be routed to a named reviewer, and the money path has no model inside it, so the ledger keeps computing and posting without one.

Yes. Each proposal carries its source data and reason, and the account trail keeps the data accessed, the approval and the resulting system event.