AI Logging Requirements for Banks: What to Record for Prompts, Outputs and Tool Calls After SR 26-2
Banks should record who or what acted, under which policy version, on what input, with which tool, and with what outcome (allowed, redacted, blocked or escalated). A minimum tier of identity, timestamp and decision metadata, plus an extended tier of content and retrieval detail, lets a bank answer examiner questions. Records only become evidence when they show policy was enforced at runtime.
Recording an interaction is not the same as evidencing enforcement
- Is the decision recorded at the moment of the action, by the component that made it?
- Can you show the exact policy version evaluated for any single event?
- Does the record distinguish allowed, redacted, blocked and escalated outcomes?
- Can sensitive content be excluded or redacted by configuration, with credentials never stored?
- Are retrievals and tool calls recorded with identity and access-control metadata?
- Can records be exported in a form model risk management can review and map to your SR 26-2 interpretation?
Start from the examiner's questions, not the log source
Banks deploying LLM-based assistants and agents need to show what the AI was permitted to do and what it actually did. Application logs rarely answer that on their own. They are usually scattered across systems, written for debugging, and silent about which policy applied.
The schema in this guide is a practitioner proposal, not a regulatory requirement. Before you finalize it, read SR 26-2 directly and have model risk management, legal and compliance map it to your own interpretation. Organizing record elements by examiner question keeps the design honest: if a field does not help answer who, under which policy, on what input, with which tool, or with what outcome, it probably belongs in operational telemetry rather than in the evidence record.
NIST SP 800-92 remains a useful general baseline for log management practices such as generation, storage and review. It is not specific to LLMs, so your team has to map it to prompts, outputs and tool calls.
The minimum record: six elements per event
The minimum tier should be written for every prompt, output and tool call, without exception. It carries identity, time and decision metadata, and it avoids storing content that is not strictly needed. It is small enough to retain for long periods and to query quickly.
- Actor identity: The querying user, service account or agent, and the application or channel. OWASP guidance for retrieval-based systems stresses recording the identity behind each request.
- Timestamp and event ID: A synchronized time and a unique identifier that links the prompt, output and any tool calls in one interaction.
- Policy version in force: The identifier of the policy set evaluated for that event, so a reviewer can see the rules as they stood then, not as they stand today.
- Enforcement decision: Allow, redact, block or escalate, with the rule that triggered it. Security-relevant decisions belong in the record.
- Tool call identity: Tool or system name, operation requested and whether it executed. Parameters can sit in the extended tier.
- Approver: For escalated actions, the human who approved or declined and when.
The extended record: content, retrieval and tool parameters
The extended tier adds what is needed to reconstruct an interaction in detail. It includes prompt and output content or a cryptographic hash of each, the system instructions in effect, tool parameters and returned results, and the model or endpoint used.
For assistants that retrieve documents, treat retrieval as its own log source. OWASP advises recording each retrieval with the identity of the requester and the access-control metadata of the retrieved chunks. That lets a reviewer check whether the AI surfaced material the user was entitled to see.
A withdrawn NIST draft on generative AI pointed toward provenance records covering sources, timestamps, metadata and third-party changes. It is a reference point, not current guidance, but the instinct is sound: record where content came from and what changed it.
Tool calls deserve particular care. An output that merely says something is a different risk from a tool call that moves data or changes a system. Record the parameters as sent, not only the tool name, because the parameters show what the AI attempted. Apply the same sensitive-data rules to them as to prompts.
Sensitive data, retention and residency in the log store
A complete log of every prompt and output can become a second repository of customer information, with its own exposure. OWASP guidance favors recording security metadata and decisions while excluding credentials, secrets and unnecessary sensitive prompt or response content. Credentials and secrets should never be written to logs at all.
The practical choice is among three storage modes. Full content gives the best reconstruction but the largest data-protection burden. Redacted content keeps context while removing identifiers. Hashed content proves a record has not changed and can be matched to a known input, but it cannot be read back. Many banks will use the minimum tier everywhere and reserve full or redacted content for higher-risk use cases, with access restricted and audited.
If the log store holds customer information, the safeguards rule at 16 CFR Part 314 is relevant where it applies. It covers financial institutions under FTC jurisdiction, so confirm which safeguards requirements govern your institution. As of November 2026, it calls for reasonable administrative, technical and physical safeguards, regular monitoring of key controls, and encryption of customer information in transit and at rest, with compensating controls approved by the Qualified Individual where encryption is infeasible.
Retention periods and data residency should be set with legal and compliance, then applied by configuration, not by convention. Make the log store tamper-evident by design, for example with append-only storage and integrity checks, so records can be trusted when produced.
Policy enforcement in the execution path
Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call is allowed, redacted, blocked, rate limited or escalated for human approval, and that decision is enforced at runtime, not reviewed after the fact. The enforcement itself produces audit-ready evidence, which is mapped to frameworks including NYDFS and NIST. Its scope is individual interactions and tool calls.
Trussed can be deployed self-managed in the customer's cloud, with configurable retention and data residency. It has run continuously in production in a regulated enterprise for more than 18 months, and its customers span four regulated verticals: insurance, pharma, healthcare and education. Insurance is the regulated financial sector where Trussed is deepest.
Whatever you choose, hold it to the criteria above. The test is whether the records show policy was enforced, not only that traffic was observed.
Examiner question to record element
Who or what acted?
User, service or agent identity and the application involved.
Under which policy?
The policy version in force at the moment of the interaction.
On what input?
Prompt content, or a hash and classification of it, plus retrieved context.
With which tool?
Tool name, target system and parameters as called.
With what outcome?
Allowed, redacted, blocked or escalated, and who approved.
Test your records against the examiner's questions
Walk through how enforcement at runtime produces audit-ready evidence for prompts, outputs and tool calls.
See How Evidence Is ProducedHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.