Glossary · Lokta concept vocabulary

Audit-by-design

Audit-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.

Event and actor
Rule and approval
Reconstruct the change

Illustrative example

A borrower disputes a late-payment charge from fourteen months ago. On a platform built audit-by-design the servicing officer opens the account and reads the event: the repayment that bounced, the day it was stamped, the charge rule in force, the agent that applied it and the approval it carried. The reply goes out the same day with the trail attached. Without it, the officer is emailing three teams for logs and screenshots.

It is a property of the data model, not a feature added later. Every state change is timestamped, attributed to an actor (user, workflow, agent), linked to the policy version it was evaluated against, and immutable downstream of approval. Audit-by-design is what allows AI to be deployed in regulated lending workflows; the alternative, bolt-on logging and screenshotted approvals, collapses the moment a regulator asks for a methodology trail.

For the post-approval book this is the property that decides whether autonomy is safe to expand. Every waiver, date change, plan, settlement and write-off has to answer four questions later: what changed, who or what changed it, under which policy version, and with whose approval. When the platform writes those answers at the moment of the change, the answer to a supervisor, an auditor or an ombudsman is a query. When it does not, the answer is a reconstruction project. Regulators set audit-trail expectations for exactly this reason; in India they sit in the RBI's IT governance direction for regulated entities, and supervisory guidance elsewhere asks for the same evidence.

See how the agentic loan servicing platform records every action →

What should a lending system’s audit trail record?

For every change to a loan: the value before and after, when it took effect, the actor who made it (a person, a workflow or an agent), the policy version it was checked against, the approval it carried and the inputs it relied on. The trail should be append-only, so a correction arrives as a new entry and the original stays readable.

How is audit-by-design different from keeping logs?

Logs record that something happened; audit-by-design records enough to replay it. A log line saying a charge was applied is not an audit trail unless it also carries the actor, the policy version, the approval and the inputs, and unless it cannot be edited after the fact. The difference is structural. Audit-by-design is a property of the data model, so every write carries its own evidence, while logging is a feature that has to be remembered, configured and kept.

What does audit-by-design require of an AI agent?

That its actions are recorded identically to a person’s. The agent’s proposal, the evidence it cited, the policy the core checked it against, the decision and the posting all land on the same append-only trail a human action would. That symmetry is what lets a lender show a regulator that the agent was governed, rather than assert it, and it is why an agent that writes to a separate log of its own is not audit-by-design.

Can audit-by-design be retrofitted to a legacy LMS?

Partly, and expensively. A lender can add logging, maker-checker screens and a change-history table to an old system, but the record will only be as complete as the integrations feeding it, and every bypass, batch fix and vendor script leaves a gap. The alternative is a platform where the trail is written by the same transaction as the change, which is a property a lender buys rather than one it bolts on.