Credit scoring, insurance and fraud: where AI decisions need a black box

Some AI decisions are low-stakes. A recommendation for a podcast is not the same as a decision that denies a mortgage, reprices an insurance policy, or freezes a payment. The second group - high-stakes, regulated, individual-affecting - is where an auditable record stops being optional.

This post walks through the three use cases we see most often, and what a defensible record looks like for each.

Credit decisions

A credit approval is the textbook "legal or similarly significant effect." When a customer is declined, they (and a regulator) will ask why. McKinsey has long modelled the impact of AI on banking, and Deloitte and EY both frame AI-in-financial-services controls around trust and risk. A defensible record captures the model version, the relevant inputs (references, not raw PII), the score, and the routing outcome - signed and chained. If the decision is disputed, you answer with evidence, not recollection.

In practice, that means when a customer asks why they were declined, the record shows the exact model version, the input references, the score band, and the routing outcome - all signed and chained. The auditor verifies the receipt offline against your published key. No screenshots, no console screenshots, no recollection.

Insurance pricing

Similar duty, different model. Rating decisions affect premiums and coverage. The record must show the logic was applied as documented, and that nothing was altered after the fact. Hash-chaining makes post-hoc edits detectable, which is exactly what an auditor wants to see.

For a pricing dispute, the record proves which model version generated the premium, what risk factors were considered, and that the chain has not been broken since the decision was signed.

Fraud detection

Fraud flags are high-volume and high-consequence: a false positive can freeze a legitimate customer. Here the record's job is continuity - proving the chain of decisions is intact across millions of events, and that any individual flag can be replayed and verified offline.

For a fraud investigation, the record lets you replay the exact decision sequence for a specific event, verify the model version that flagged it, and prove the chain has not been edited since.

What a defensible record contains (all three)

• Your organisation's signature (Ed25519), not the vendor's.
• A content hash of the decision inputs and outputs.
• A chain hash linking to the previous decision.
• An independent RFC 3161 timestamp.
• Captured governance: model version, score, routing outcome, actor type.
• Verifiable erasure so retention expiry is demonstrable.

How Decision Keep fits

Decision Keep sits beside your models and produces this record for every decision - sovereign and verifiable, so the evidence never leaves infrastructure you control. Auditors verify offline against your published key.

For the minimum evidence your board should expect, see Proving AI decisions to your board: a 1-page evidence checklist.

• Verify a sample receipt
• Read the receipt specification
• See how it maps to APP 1.7–1.9 and the EU AI Act
• Book a demo