---
title: "Auditable memory for financial services AI"
description: "Financial services AI must answer what was known when. Point-in-time recall, supersession, provenance and retention make agent memory reviewable."
canonical: https://past.dev/industries/financial-services
last-updated: 2026-09-02
---
# Auditable memory for financial services AI

Source: https://past.dev/industries/financial-services

Financial services AI needs memory that can be reviewed after the fact. When an agent flags, recommends or approves, the follow-up question arrives months later: what did the system know on that date. Answering it takes point-in-time recall over event-time records, supersession for customer facts that change, provenance on every recalled fact, and retention horizons per record class. A memory layer that keeps only a current summary cannot reconstruct its own past state, so its decisions cannot be explained or defended.

## Reviews ask what was known when

Financial services work is reviewed after the fact. A complaint lands six months after the interaction. Internal audit samples last year's recommendations. A model review asks why the system flagged one transfer and cleared another. Every one of these reduces to the same shape: on the date the agent acted, which facts applied, and which sources established them.

Reconstructing the state of knowledge on a past date is [point-in-time recall](/glossary/point-in-time-recall). A store can only do it if it recorded change instead of erasing it, which makes the storage model a review-readiness decision made long before any review happens.

## Customer facts change, and generic memory overwrites them

The facts an agent uses most are the facts that change most. Each carries a question that will be asked about a past date.

| Customer fact | Typical change | Question a review asks later |
| --- | --- | --- |
| Registered address | Moves on notice from the customer | Which address was on file when the disclosure went out on March 3 |
| Risk profile | Revised after an annual review call | Which profile applied to the recommendation of March 20, 2026 |
| Employment and income | New employer, new figure | Which income figure supported the affordability assessment |
| Holdings | Change with every trade and deposit | What the position was on the review date |

A chat-style memory keeps one current summary per customer. It answers today's questions and none of the historical ones, because overwriting destroys the prior value and appending without linkage cannot say which value applied on a given date. The storage strategies and their failure modes are compared in [facts that change over time](/guides/facts-that-change-over-time) and [bitemporal data](/guides/bitemporal-data).

## What the memory layer must provide

- **Event time on every fact.** A customer notice dated April 2 takes effect April 2 even if it was processed April 9. Reviews can ask about either date, which is the [event time vs ingestion time](/guides/event-time-vs-ingestion-time) distinction; keeping both axes makes the store [bitemporal](/glossary/bitemporal-memory).
- **Supersession for every changed fact.** The old value's [validity window](/glossary/validity-window) closes at the change date and the new value links back. Both stay queryable with their dates.
- **Provenance on every recalled fact.** A recommendation defended in review needs the source behind each supporting fact: the document, the call, the date. That contract is [data provenance](/guides/data-provenance).
- **A recall status the agent can act on.** When evidence is missing or credible sources disagree, the store should report that state rather than return a confident guess. Recorded disagreement is covered in [contradictory facts](/guides/contradictory-facts).
- **Retention and erasure per record class.** Some records carry multi-year retention horizons while personal data can carry erasure duties. Per-class [retention](/guides/ai-data-retention) and source-level [deletion](/guides/gdpr-memory-deletion) keep the two obligations from colliding.
- **An audit trail for the memory itself.** What was ingested, when, from where, and what each recall returned. The [AI audit trail guide](/guides/ai-audit-trail) describes the shape of that record.

All six behaviors can be tested with dated probes before any integration work. The [benchmark methodology](/benchmarks/methodology) describes how point-in-time and update probes are constructed and scored.

> **Memory is one layer of the record**
>
> Core banking, trading and CRM systems remain authoritative for balances, positions and contracts. The memory layer records what the agent knew, when it knew it, and where each fact came from. The two records answer different review questions and neither substitutes for the other.

## A worked example: one recommendation, one review

Priya Raman has held an account since January 2024. Her file changes once, an agent acts once, and a review reconstructs it all.

| Date | Event | Store after the event |
| --- | --- | --- |
| Jan 15, 2024 | Account opened, risk profile recorded as growth | One profile fact, window open from Jan 15, 2024 |
| Nov 14, 2025 | Annual review call revises the profile to conservative | Growth fact closes at Nov 14, 2025 and links forward; conservative fact opens, source: the call transcript |
| Mar 20, 2026 | Agent recommends rebalancing toward bonds | Recommendation recorded together with the facts it relied on |
| Aug 11, 2026 | Complaint review reconstructs the March recommendation | Recall as of Mar 20, 2026 returns the conservative profile, valid since Nov 14, 2025, with the transcript as evidence |

```theriskprofilefactsthereviewreads
[
  {
    "id": "fact_5e2",
    "subject": "customer-priya-raman",
    "predicate": "risk_profile",
    "value": "growth",
    "valid_from": "2024-01-15",
    "valid_to": "2025-11-14",
    "superseded_by": "fact_c90",
    "source": "onboarding-form-2024-01-15"
  },
  {
    "id": "fact_c90",
    "subject": "customer-priya-raman",
    "predicate": "risk_profile",
    "value": "conservative",
    "valid_from": "2025-11-14",
    "valid_to": null,
    "superseded_by": null,
    "source": "call-transcript-2025-11-14"
  }
]
```

The review closes on the record: the March recommendation was made under the conservative profile, in force since November 14, 2025, supported by a dated transcript. Without supersession the store would show only the current profile, and the reviewer would rebuild the timeline by hand from mailboxes and call logs.

## Where past.dev fits

past.dev stores each fact with event time, a validity window and a supersession link, and recall returns current and previous values with dated evidence plus one of four status values: Supported, Conflicted, NoKnownSupport or UnknownBecauseDegraded. It holds SOC 2 Type II, ISO 27001 and ISO 27701 certifications, and regulatory obligations remain with the institution. The [quickstart](/docs/memory-api/quickstart) shows the API, and [self-hosting](/docs/memory-api/self-hosting) keeps memory in the institution's own Postgres.

## Frequently asked questions

### How do I audit what an AI agent knew when it made a recommendation?

Store every fact with the date it became true and the source that established it, and close old values instead of overwriting them. A review then queries the state as of the decision date and gets the facts that applied, each with dated evidence.

### What should AI memory do when a customer's risk profile changes?

Record the new profile as of the change date, close the old profile's validity period, and keep the two linked. Recommendations made before the change stay explainable under the old profile, and new ones use the current profile.

### Is past.dev compliant with financial services regulations?

No memory vendor can make an institution compliant, and past.dev does not claim to. It holds SOC 2 Type II, ISO 27001 and ISO 27701 certifications and provides the mechanisms reviews rely on, including dated records, provenance, retention controls and erasure by source, while the regulatory obligations remain with the institution.

### Can agent memory serve as the system of record for customer data?

Treat it as the agent's memory layer rather than the book of record. Core banking and CRM systems stay authoritative for balances and contracts, while the memory layer records what the agent knew, when it knew it, and where it came from.

## Related

- [Legal AI](https://past.dev/industries/legal)
- [Accounting AI](https://past.dev/industries/accounting)
- [Bitemporal data](https://past.dev/guides/bitemporal-data)
- [AI audit trail](https://past.dev/guides/ai-audit-trail)
- [AI data retention](https://past.dev/guides/ai-data-retention)