Audit Trails for LLM Features in Fintech: What to Record

An LLM feature in a fintech product rarely makes the final call on its own. It drafts the dispute summary, flags the unusual transaction, suggests the next KYC question or pre-fills the credit memo that an analyst signs. Later, when a customer complains, an internal auditor samples cases or a supervisor asks how a decision was reached, someone has to reconstruct exactly what the system saw and did.

That is usually the moment a team finds it kept application logs, not an audit trail. This post covers what to record for each decision an LLM touches, how to store it so it can be trusted, how long to keep it, and why a model's explanation is not the same thing. It is engineering guidance for SI in fintech products, not legal advice: what your firm must keep is a question for your compliance and legal teams.

An explanation is not an audit trail

Two things get confused. An explanation is the reason the system gives for an output, such as "flagged because the merchant pattern matches earlier chargebacks". It is generated, often by the same model, and it can be plausible without being the true cause. An audit trail is the evidence: the exact inputs, versions and steps that produced the output, captured at the time by the system rather than written by the model.

You need both, but they answer different questions. The explanation helps the analyst and the customer understand the result. The trail lets an independent reviewer reconstruct the decision and check that the explanation matches what actually happened.

If the only record of why the model did something is the model's own account, you do not have an audit trail.

What should an audit trail for an LLM feature record?

An audit trail for an LLM feature should record enough for an independent reviewer to reconstruct every decision the feature touched. Give each decision a stable id that links all model calls, tool calls and human steps. For each one, keep the prompt template and its version, the model identifier the provider returned and the sampling parameters, the retrieved sources by document id plus version or hash, every tool call with its arguments and results, the raw and final output, and the human review: who approved, their role, what they saw and what they accepted. Store it as append-only, hash-chained events in storage that resists deletion, keep personal data pseudonymised or in a separate store with its own deletion path, and take retention periods from your compliance team. A model-written explanation is useful context, but it is not the audit trail, because the trail must be captured by the system rather than described by the model.

What to record for every decision an LLM touches

Think in decisions, not in API calls. Give each decision a stable id that links every model call, tool call and human step inside it, then capture the following.

• Decision context: the decision id, a pseudonymous case or account reference (not a name), the business process, the user or service that triggered it, and timestamps for each step.
• Prompt and template version: the template id and version from source control, the system instructions in force and the variables that filled the template. Store each template once and reference it by version, so the record shows exactly which wording was live.
• Model and parameters: the provider, the model identifier the API actually returned (not only the alias you requested), temperature and other sampling settings, output limits and any moderation or safety settings applied.
• Retrieved sources: for RAG features, the document ids, their versions or content hashes, the passages passed to the model and the retriever and index version. "The lending policy" is not enough when the policy changed last quarter.
• Tool calls: each tool name, its arguments, the result it returned, errors and retries, in order. If the model asked a limits or pricing service for data, record what that service answered.
• The output: the raw model output, the structured fields parsed from it, validation results, and what was finally shown to a person or sent downstream after filters.
• Human approval: who reviewed, their role, what was on screen, whether they approved, edited or rejected, the final version they accepted and when.
• Later changes: an override by a person or a downstream rule is a new event linked to the same decision id, not an edit to the old one.

The human step deserves the most care. The approval patterns in human-in-the-loop design for SI agents only hold up under review if the trail shows the reviewer was named, had the authority to approve, and saw the same draft the record says they approved.

How do you make the store tamper-evident?

A trail that an administrator can quietly edit proves very little. The aim is that any change after the fact is either impossible or detectable.

• Write records as append-only events. A correction is a new event that references the old one, never an update in place.
• Chain the events: each record carries a hash of its own content and the hash of the record before it, so removing or altering one breaks the chain. Anchor the latest hash somewhere separate on a schedule, such as a signed checkpoint in another account.
• Use storage that enforces retention, such as object storage with write-once or retention-lock settings, and keep its admin rights away from the application team.
• Separate duties: the service that writes the trail should not be able to delete it, and every read of the trail should itself be recorded.
• Verify it continuously. A scheduled job should check the hash chain, sample records for missing fields and alert when a decision has no trail at all.

Some financial rules already describe these two designs. The SEC's broker-dealer recordkeeping rule, for example, accepts either a non-rewriteable, non-erasable format or a system with a complete time-stamped audit trail that allows the original record to be re-created after a change or deletion. Whether that rule covers your records is a legal question, but the two patterns it names are sound engineering either way.

Retention, and keeping personal data out of the chain

How long to keep the trail is set by the rules that apply to your firm and product, not by a logging vendor's default. The EU AI Act is one example. For systems in its high-risk categories, which include evaluating the creditworthiness of individuals, it requires the system to technically allow automatic recording of events over its lifetime and sets a minimum period for keeping those logs. Financial institutions under EU financial services governance rules keep those logs within their existing documentation. The high-risk dates were moved back by a 2026 amendment, so check the current position.

Retention pulls against privacy: immutable records full of names, account numbers and free-text prompts are a liability. Keep personal data out of the chain where you can: refer to customers by pseudonymous ids, hold sensitive payloads encrypted in a separate store with its own retention and deletion process, and keep only references and hashes in the immutable chain. You can then delete or crypto-shred personal data when the law requires it without breaking the chain. The logging side of this is covered in what to log from an LLM app without storing personal data.

Can someone outside the team replay a decision?

The real test is whether a reviewer who did not build the feature can take a decision id and reconstruct it: the template text, the model and settings, the sources as they stood that day, the tool results, the output and the approval. Two things make this harder than it sounds.

First, models change under you. Hosted models are updated and aliases move to new versions, so record the exact identifier the provider returned and keep evaluation results for every version that ran in production. Second, LLM output is not deterministic, even with identical inputs. Replay means showing what the system received and produced, not regenerating the same text. The record is the proof, not a rerun.

This is where audit and evaluation meet. If every template, model and retrieval change goes through an eval-first release process, each version in the trail has a matching test report showing how it performed before it went live. That pairing, what ran plus how it was tested, is what makes a feature audit-ready rather than merely logged. Supervisory expectations are still moving: the US banking agencies replaced their model risk guidance in 2026 and left generative and agentic systems outside its scope for now.

A checklist before an LLM touches a regulated decision

1. Every decision has one id that links model calls, tool calls and human steps.
2. Template, model, parameters and index versions are recorded per call, not per deploy.
3. Retrieved sources are referenced by id plus version or hash.
4. Tool calls and their results are captured in order, including failures and retries.
5. Approvals record the person, their role, what they saw and what they accepted.
6. The store is append-only, hash-chained and verified on a schedule.
7. Personal data is pseudonymised or held separately with its own deletion path.
8. Retention periods come from your compliance team, in writing, per record type.
9. Someone outside the team has reconstructed a sample of decisions from the trail alone.
10. Model-written explanations are stored as outputs, never as the record of cause.

If that list feels heavy for an internal drafting tool that never touches a customer decision, it probably is. Ordinary application logs and good evaluation may be enough there. The full trail earns its cost where a person or a regulator may later ask why a specific customer got a specific outcome.

Where to start

If an LLM feature is already in production, pick one decision type and try to reconstruct a recent case from what you store today. The gaps are usually the same: missing template versions, retrieved sources recorded by name rather than version, and no record of what a reviewer changed.

If you are building one now, design the decision record before the prompt. Our MLOps and SI infrastructure team builds this kind of trail into LLM features from the first release, and our work with fintech product teams starts from the decisions that will be reviewed later. If you would like a plain answer on what an auditor would find missing in your current logs, Octalcode is happy to look with you.