Audit Trail
An audit trail is the chronological, tamper-evident record of who did what, when, and on whose authority — every transaction, approval, configuration change and decision in a system. In a regulated financial business it is what turns "we have controls" into evidence, and in an acquisition it is the first thing a buyer's technical and compliance diligence asks to see.
- Also known as
- Audit log, Activity log
- Used at
- every regulated system — payments, lending decisions, KYC approvals, model changes — and in due diligence on all of them
- Binding
- yes, by regulation — PCI DSS requirement 10 (logging and monitoring), SOC 2's monitoring criteria, AML record-keeping of five years or more, DORA's ICT logging in the EU
- Typical retention
- 5–7 years for transaction and customer records; 12 months online for security logs under PCI DSS, with 3 months immediately available
- Parties
- the operator, its auditors and regulators, and any acquirer
How an audit trail works in practice
A usable audit trail answers a reconstruction question: for this payment, this credit decision, this customer approval — what happened, in what order, by which person or system, and could any of it have been altered afterwards. That needs four properties. Each event is timestamped from a trusted clock. Each carries an actor — a named user, a service account, a model version — not a shared login. The log is append-only and its integrity checked, so a deleted or edited line is visible. And it is searchable within the time a regulator gives you, which is days, not weeks.
In fintech the trail now extends into decisions made by software. A lender using a scoring model must show, for a declined applicant, the inputs the model saw, the version that ran and the reason it produced; a payments company must show why a transaction was blocked. Where an AI agent acts — approving a refund, closing a case — the trail records the agent's instructions, the tools it called and the human who could have overridden it.
In diligence a buyer picks transactions at random and asks the seller to reconstruct them end to end. A company that can do it in an hour has controls; one that needs a week has a promise.
Example
A buyer of a consumer lender samples 50 declined applications from the past year. For 46 the seller produces the full trail in a day: application data, model version 3.2, score, reason codes, the adverse-action notice sent. For 4, decided during a model migration in March, the model version is missing and the reason codes cannot be reproduced. The lender made 1.2m decisions that year; the same migration window covers roughly 40,000 of them. The buyer prices a regulatory remediation at £600,000 and takes a specific indemnity for complaints from that window, and the seller accepts both rather than delay signing.
Common mistakes
- Logs written by the application that the application can also edit or delete. - Shared administrator accounts, so the trail says "admin" and identifies nobody. - Keeping the data but not the model version or rule set that produced a decision. - Retention set by disk space rather than by the regulation. - Treating the audit trail as a security feature and discovering in diligence that it is a valuation one.