AI audit trails in banking and insurance products

A bank or insurer should show an AI-assisted decision on four surfaces and record it on all of them: a customer notice that gives the real reasons and a way to contest, an operator screen that shows the evidence and lets a person override with a reason, a log that nobody can edit after the fact, and a compliance view that lets a reviewer replay who decided what, on which model version and data, and when. In a regulated product, an AI decision that is not recorded did not happen properly. Teams design the model's explanation for the customer and stop. The operator's override and the auditor's log are the screens a regulator will ask to see.

This is design guidance, not legal advice. Your compliance and legal owners decide what your product must do.

Who needs what record

Each party reads a different record of the same decision. Design them from one underlying event, so they cannot disagree.

What the rules actually say

Three sets of rules shape these screens. Check each against your own jurisdiction and product.

United States, lending. Under Regulation B, which implements the Equal Credit Opportunity Act, a creditor taking adverse action must give a written notice with "a statement of specific reasons for the action taken". The statement of reasons must be specific and indicate the principal reason(s) for the adverse action, and saying only that the creditor's internal standards or policies drove the decision is not enough. The CFPB applied this to complex models in Circular 2022-03, which said the requirements apply "regardless of the technology used", and in Circular 2023-03 on sample forms. Their status has changed. The 2023-03 page is now marked archived, and law-firm reports say the CFPB withdrew both circulars in May 2025 among 67 guidance documents and would not enforce them while it reviewed them. We could not confirm that from the CFPB's own withdrawal list, and the 2022-03 page shows no withdrawal notice. The regulation itself is unchanged, so design to the regulation.

European Union, high-risk AI. The AI Act lists in Annex III point 5(b) systems that evaluate the creditworthiness of natural persons or set their credit score (fraud detection excepted), and in point 5(c) systems used for risk assessment and pricing of natural persons in life and health insurance. For these, Article 12 says high-risk systems must technically allow the automatic recording of events (logs) over their lifetime. Article 13 requires enough transparency for deployers to interpret and use the output. Article 14 requires that people can oversee the system, including deciding in a situation not to use it or to disregard, override or reverse its output. The application date for Annex III obligations was 2 August 2026, but we found that Regulation (EU) 2026/1744, the AI Omnibus, which entered into force on 27 July 2026, moves it to 2 December 2027. We read the article wording at an unofficial mirror and the new date in a published summary, because we could not open EUR-Lex pages with our tools, so confirm both on EUR-Lex.

United States, insurance. The NAIC adopted its Model Bulletin on insurers' use of AI systems in December 2023. It sets out expectations for how insurers govern AI and tells them what information a department may request in an investigation or examination. It is guidance that each state adopts for itself. We could not verify a current count of adopting states, so check your states directly.

The pattern across all three is the same: the customer is told why, a person can intervene, and a record exists that a reviewer can read later.

The customer notice

The notice is the surface teams design best, and still get wrong when the model's output is passed straight through. Check it against this list.

• States the decision in the first sentence, in plain words.
• Gives the principal reasons the decision actually turned on, not a generic list and not "internal standards".
• Uses reasons a person can act on or dispute, written in the customer's language rather than model feature names.
• Says how to contest, correct data or ask for a person to look again, with a working route in the product.
• Matches the record. The reasons shown are the reasons stored, from the same event.
• Names a human contact or channel, and states any deadline that applies in your jurisdiction.
• Is kept as the customer saw it, with the version of the template.

The anatomy of an override

The override is where human oversight becomes evidence. A button is not enough. An override that leaves no trace is invisible to the compliance team, and one that is too easy trains operators to accept whatever the system says.

1. The recommendation, shown as a recommendation. Label what the model proposed and show the evidence beside it: the inputs that mattered, data quality flags, and any confidence the system can honestly state.
2. Three clear actions. Accept, change, or reject the output, each equally reachable.
3. A reason, required for change or reject. Offer a short list of reason codes plus a written note, so the compliance team can group overrides and read the exceptions.
4. A second look when the stakes call for it. Route high-value or sensitive overrides to another person.
5. A stored result. The operator, the time, the original output, the final decision, the reason, and the model version, all written together.
6. A way back to the customer. If the override changes the outcome, the notice is regenerated from the final decision, not the model's.

Accepting also has to be recorded. A log that holds only overrides makes it impossible to tell a considered approval from a click-through.

The reviewable log

Treat the log as a product surface, with its own design and users. Check it against this list.

• Append-only. Entries are never edited or deleted; corrections are new entries that point to the old one.
• One record per decision, with a stable identifier shown on the operator screen, so a complaint can be traced to it.
• Model version and configuration at the time of the decision.
• Inputs as the model received them, or a reference that reproduces them, including data sources and their timestamps.
• Output and the reasons generated, as the customer and operator saw them.
• Human action: who, what, the reason code and the written note.
• Timestamps for each step, in one agreed time zone.
• Notices sent, with the template version.
• Retention that matches your legal duties. The AI Act, as we read it, asks deployers to keep high-risk system logs for a period appropriate to the purpose, of at least six months, and financial institutions can hold them with their existing documentation. Your data protection duties may pull the other way, so set this with counsel.
• A reader's view: search by customer, model version, operator and outcome, and an export a regulator can take away.

Show consequences before action

One part of this is not specific to AI. We designed workflow software for insurance producer payouts, Chestnut, where publishing a change to a template names every workflow it will reach before it goes live, and releasing a producer or policy hold asks what should happen to the held funds before anything is confirmed. It is not an AI project. We cite it only for the principle: an operator who can see what an action will touch makes a better-recorded decision. The same applies when an override reverses a model's decision on a loan or a claim.

Where the interface has to explain how people stay in control of an AI decision, our work on trust, control and recovery covers the wider patterns. Our fintech and insurtech page shows the regulated products we design.

What we left out

We have not covered the UK or other jurisdictions, fair lending testing of the model itself, or model validation. A regulator may also ask for evidence your product does not store today, which is the reason to put the log in the design early and not add it after launch. The compliance and legal owners at your company decide what each rule requires of your product.