Some of the risk-committee materials in front of Credit Suisse's senior management before the Archegos collapse were four to six weeks old by the time anyone read them, a byproduct of how long preparation and data-scrubbing took. The information wasn't false. Every figure had been accurate on the day it was recorded. It just wasn't a picture of the risk the bank was actually carrying by the time it reached the people meant to act on it, and known limit breaches were allowed to persist rather than triggering the kind of urgent escalation a live number would have demanded.
That's the distinction leadership decisions need and accuracy checks don't give them. Accuracy asks whether a value was correct when it was recorded. The question that actually matters in a meeting is different: is it still fit for the decision being made right now? A price, an eligibility rule, a risk exposure, an operating metric, any of these can become dangerous without a single stored character changing, purely because the world underneath them moved and the number didn't.
The same mechanism shows up outside finance too. One large study of AI systems working with changing factual information found that adding outdated context could reduce answer performance by at least 20%, even when the current, correct information was sitting right there in the same context. The old answer wasn't nonsense. It was coherent, well-formed, and confidently wrong, which is exactly what made it dangerous.
Four clocks, not one timestamp
"Last updated" isn't enough, and Credit Suisse's own post-mortem response makes that concrete: after the collapse, the bank moved to daily reporting of Prime Services exposure, tighter limits, mandatory minimum margins, and strict remediation deadlines, changing cadence, ownership, and escalation together rather than tweaking one dial. A trustworthy record distinguishes when the source changed, when the pipeline refreshed, when the definition was last verified, and which version is authoritative. A technical refresh that runs perfectly on schedule can still be feeding an obsolete policy or an unverified business rule into every downstream decision.
Freshness should be set by consequence, not by convenience. A company-history document can tolerate being months stale. A pricing rule, a risk exposure, or a compliance policy usually can't. The right question was never "how often should everything refresh?" It's narrower and more useful: how old can this specific thing be before using it creates a risk somebody would need to explain afterward?
Make staleness visible
Give decision-critical data an effective date, an expiry or review rule, an authoritative version, and an accountable owner, someone who can say yes or no when asked whether it's still good enough. When those fields are visible to both the system and the person using its output, outdated information becomes a condition somebody's actively managing. Without them, it's a surprise waiting for the moment it's expensive.